Re: pg_dump and pgpool

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump and pgpool
Дата
Msg-id 18884.1104363042@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump and pgpool  (Scott Marlowe <smarlowe@g2switchworks.com>)
Ответы Re: pg_dump and pgpool
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: debug_print_plan (pg7.4) doesn't seem to do anything
Следующее
От: Eric Brown
Дата:
Сообщение: Re: debug_print_plan (pg7.4) doesn't seem to do anything