Re: pg_dump and pgpool - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_dump and pgpool
Date
Msg-id 18884.1104363042@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump and pgpool  (Scott Marlowe <smarlowe@g2switchworks.com>)
Responses Re: pg_dump and pgpool  (Scott Marlowe <smarlowe@g2switchworks.com>)
List pgsql-general
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> On Wed, 2004-12-29 at 16:56, Tom Lane wrote:
>> No, we'd be throwing more, and more complex, queries.  Instead of a
>> simple lookup there would be some kind of join, or at least a lookup
>> that uses a multicolumn key.

> I'm willing to bet the performance difference is less than noise.

[ shrug... ]  I don't have a good handle on that, and neither do you.
What I am quite sure about though is that pg_dump would become internally
a great deal messier and harder to maintain if it couldn't use OIDs.
Look at the DumpableObject manipulations and ask yourself what you're
going to do instead if you have to use a primary key that is of a
different kind (different numbers of columns and datatypes) for each
system catalog.  Ugh.

I don't think it's worth that price to support a fundamentally bogus
approach to backup.  IMHO you don't want extra layers of software in
between pg_dump and the database --- each one just introduces another
risk of getting a wrong backup.  You've yet to explain what the
*benefit* of putting pgpool in there is for this problem.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: debug_print_plan (pg7.4) doesn't seem to do anything
Next
From: Eric Brown
Date:
Subject: Re: debug_print_plan (pg7.4) doesn't seem to do anything