In the belly of the beast (MySQLCon)

Dude, you have got to let us know how that goes...

On Apr 17, 2008, at 1:29 PM, Joshua D. Drake wrote:

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders who
are doing a little Dolphin hunting are about... I am in Ballroom E
about to give a talk on what Mysql can learn from PostgreSQL.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

Erik Jones

DBA | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

Joshua D. Drake wrote:

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders who
are doing a little Dolphin hunting are about... I am in Ballroom E
about to give a talk on what Mysql can learn from PostgreSQL.

Check the room for barrels of tar and feathers before you start your
presentation...

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

On Thu, Apr 17, 2008 at 11:29 AM, Joshua D. Drake <jd@commandprompt.com> wrote:

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders who
are doing a little Dolphin hunting are about... I am in Ballroom E
about to give a talk on what Mysql can learn from PostgreSQL.

is there a live video feed those of us not attending can watch?
I've got my popcorn in the microwave already...

On Thu, 17 Apr 2008 11:29:56 -0700
"Joshua D. Drake" <jd@commandprompt.com> wrote:

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders
who are doing a little Dolphin hunting are about... I am in
Ballroom E about to give a talk on what Mysql can learn from
PostgreSQL.

Is your presentation available online at all?

Hope it goes well,

Josh

On Thu, 17 Apr 2008 22:19:23 -0500
Josh Trutwin <josh@trutwins.homeip.net> wrote:

Is your presentation available online at all?

Blogging the bad boy up right now.... Will be available soon.

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

On Thu, 17 Apr 2008 16:43:04 -0400
Geoffrey <lists@serioustechnology.com> wrote:

Joshua D. Drake wrote:

Hello,

I am currently chilling at MySQLCon. If any other Elephant riders
who are doing a little Dolphin hunting are about... I am in
Ballroom E about to give a talk on what Mysql can learn from
PostgreSQL.

Check the room for barrels of tar and feathers before you start your
presentation...

O.k. the presentation can not be found on planet...
www.planetpostgresql.org .

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

jd@commandprompt.com ("Joshua D. Drake") writes:

On Thu, 17 Apr 2008 22:19:23 -0500
Josh Trutwin <josh@trutwins.homeip.net> wrote:

Is your presentation available online at all?

Blogging the bad boy up right now.... Will be available soon.

The presentation seems pretty good...

... But what is more interesting is what was the reaction?

I note in the blog that the "in place upgrade" issue came up.
(Interesting to observe that it *also* came up pretty prominently in
the intro session at PG East... This is obviously a matter of Not
Inconsiderable Interest...) It would be nice to hear what other
things got a reaction. Of course, some of that may be yet to arrive,
as there are doubtless conversations yet to happen!
--
"cbbrowne","@","cbbrowne.com"
http://www3.sympatico.ca/cbbrowne/spiritual.html
FLORIDA: We've been Gored by the bull of politics and we're Bushed.

On Friday 18 April 2008, Chris Browne <cbbrowne@acm.org> wrote:

I note in the blog that the "in place upgrade" issue came up.
(Interesting to observe that it *also* came up pretty prominently in
the intro session at PG East... This is obviously a matter of Not
Inconsiderable Interest...)

Upgrades are certainly the biggest PostgreSQL operational issue for me.

Uhh, boss, I need to bring the database down for 3 days to do an upgrade.
Yes, that means clients can't do anything during that time. Boss - !!@#@#$#

Hence why I'm still running 8.1 ....

--
Alan

Alan Hodgson wrote:

On Friday 18 April 2008, Chris Browne <cbbrowne@acm.org> wrote:

I note in the blog that the "in place upgrade" issue came up.
(Interesting to observe that it *also* came up pretty prominently in
the intro session at PG East... This is obviously a matter of Not
Inconsiderable Interest...)

Upgrades are certainly the biggest PostgreSQL operational issue for me.

Uhh, boss, I need to bring the database down for 3 days to do an upgrade.
Yes, that means clients can't do anything during that time. Boss - !!@#@#$#

Hence why I'm still running 8.1 ....

What about the:

8.1 -> slony -> 8.3
switch users to 8.3 databases

solution.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

On Fri, 18 Apr 2008 13:54:52 -0400
Geoffrey <lists@serioustechnology.com> wrote:

What about the:

8.1 -> slony -> 8.3
switch users to 8.3 databases

solution.

Is it? What is your transactional velocity? How long will the initial
sync transaction have to run? You know vacuum isn't working while
that transaction is open right? Are you going to have to setup up a
dozen different replicated sets in order to get it done?

Slony works in "some" cases it does not work in all nor the most
critical (in terms of large sets with minimal downtime requirement).

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:

On Fri, 18 Apr 2008 13:54:52 -0400
Geoffrey <lists@serioustechnology.com> wrote:

What about the:

8.1 -> slony -> 8.3
switch users to 8.3 databases

solution.

Is it? What is your transactional velocity? How long will the initial
sync transaction have to run? You know vacuum isn't working while
that transaction is open right? Are you going to have to setup up a
dozen different replicated sets in order to get it done?

Slony works in "some" cases it does not work in all nor the most
critical (in terms of large sets with minimal downtime requirement).

I don't know that slony is the answer. It was more of a question then
an answer. We are hoping to use that solution to migrate from 7.4.19 to
8.3.1. The primary reason is to reduce downtime.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <lists@serioustechnology.com> wrote:

I don't know that slony is the answer. It was more of a question
then an answer. We are hoping to use that solution to migrate from
7.4.19 to 8.3.1. The primary reason is to reduce downtime.

Well :) That is why I asked the questions I did. It very well may be
the answer. It might not. For example, what size is your database? How
many transactions per hour are you doing?

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:

On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <lists@serioustechnology.com> wrote:

I don't know that slony is the answer. It was more of a question
then an answer. We are hoping to use that solution to migrate from
7.4.19 to 8.3.1. The primary reason is to reduce downtime.

Well :) That is why I asked the questions I did. It very well may be
the answer. It might not. For example, what size is your database? How
many transactions per hour are you doing?

We have 13 separate databases, not terribly large, my WAG would be that
our largest database might have 30 million rows. I couldn't honestly
tell you how many trans/hour we are doing without doing a little research.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

On Friday 18 April 2008, Geoffrey <lists@serioustechnology.com> wrote:

What about the:

8.1 -> slony -> 8.3
switch users to 8.3 databases

solution.

15+ million row inserts/updates a day across 1000+ tables. Oh, and an
extensive existing Slony structure for some portions of the database.

I could conceivably construct Slony sets for the currently non-replicated
tables and iteratively subscribe them (so the initial subscribe doesn't
take a week ...). I'm not at all sure Slony could keep up with our update
load, though, especially not while maintaining current database operations
and also handling those subscriptions. Slony doesn't really work well with
high transaction volumes, in my experience.

I am going to play with this and see where it breaks, but it's going to be
an enormous time investment to babysit it.

--
Alan

Geoffrey wrote:

Joshua D. Drake wrote:

On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <lists@serioustechnology.com> wrote:

I don't know that slony is the answer. It was more of a question
then an answer. We are hoping to use that solution to migrate from
7.4.19 to 8.3.1. The primary reason is to reduce downtime.

Well :) That is why I asked the questions I did. It very well may be
the answer. It might not. For example, what size is your database? How
many transactions per hour are you doing?

We have 13 separate databases, not terribly large, my WAG would be that
our largest database might have 30 million rows. I couldn't honestly
tell you how many trans/hour we are doing without doing a little
research.

I find it pretty unlikely that Slony would be unable to help you upgrade
here. Obviously you can upgrade one database at a time.

Also, mostly it's not the database size what's a concern, but rather the
size of the largest table.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Fri, 18 Apr 2008 14:59:34 -0400
Alvaro Herrera <alvherre@commandprompt.com> wrote:

I find it pretty unlikely that Slony would be unable to help you
upgrade here. Obviously you can upgrade one database at a time.

Also, mostly it's not the database size what's a concern, but rather
the size of the largest table.

As I recall (I could be wrong) Slony syncs the whole set as a single
transaction. So if he has his entire database as a set he may
have a problem regardless of the largest or smallest table. I would also
agree that 30 million rows is likely not a problem but he should still
check his velocity.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Alvaro Herrera wrote:

Geoffrey wrote:

Joshua D. Drake wrote:

On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <lists@serioustechnology.com> wrote:

I don't know that slony is the answer. It was more of a question
then an answer. We are hoping to use that solution to migrate from
7.4.19 to 8.3.1. The primary reason is to reduce downtime.

Well :) That is why I asked the questions I did. It very well may be
the answer. It might not. For example, what size is your database? How
many transactions per hour are you doing?

We have 13 separate databases, not terribly large, my WAG would be that
our largest database might have 30 million rows. I couldn't honestly
tell you how many trans/hour we are doing without doing a little
research.

I find it pretty unlikely that Slony would be unable to help you upgrade
here. Obviously you can upgrade one database at a time.

Also, mostly it's not the database size what's a concern, but rather the
size of the largest table.

Well, we have done some extensive testing and it seems feasible. We've
got more testing to do, so we've not decided. We hope to use slony to
replicate the data in order to have a hot spare solution as well.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

Joshua D. Drake wrote:

On Fri, 18 Apr 2008 14:59:34 -0400
Alvaro Herrera <alvherre@commandprompt.com> wrote:

I find it pretty unlikely that Slony would be unable to help you
upgrade here. Obviously you can upgrade one database at a time.

Also, mostly it's not the database size what's a concern, but rather
the size of the largest table.

As I recall (I could be wrong) Slony syncs the whole set as a single
transaction. So if he has his entire database as a set he may
have a problem regardless of the largest or smallest table. I would also
agree that 30 million rows is likely not a problem but he should still
check his velocity.

We have actually replicated all 13 databases and there was no apparent
impact on production. This was in the evening, but we are a 24/7 shop.

I'm really not altogether sure what you mean by transaction velocity.
I'm pretty sure the electrons are traveling pretty close to the speed of
light. ;)

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

Joshua D. Drake wrote:

On Fri, 18 Apr 2008 14:59:34 -0400
Alvaro Herrera <alvherre@commandprompt.com> wrote:

I find it pretty unlikely that Slony would be unable to help you
upgrade here. Obviously you can upgrade one database at a time.

Also, mostly it's not the database size what's a concern, but rather
the size of the largest table.

As I recall (I could be wrong) Slony syncs the whole set as a single
transaction. So if he has his entire database as a set he may
have a problem regardless of the largest or smallest table.

Yes, if he does that then you are right, but it's unlikely to be the
best idea.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.