Re: [HACKERS] pg_dump and thousands of schemas

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] pg_dump and thousands of schemas
Дата
Msg-id CAMkU=1z4gVqxxvUUnFwme+LQW-8eGjwe3cf1EeG_Tjz9SevVFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_dump and thousands of schemas  (Denis <socsam@gmail.com>)
Список pgsql-performance
On Tue, Nov 13, 2012 at 7:12 PM, Denis <socsam@gmail.com> wrote:
> Jeff Janes wrote
>> On Thu, Nov 8, 2012 at 1:04 AM, Denis <
>
>> socsam@
>
>> > wrote:
>>>
>>> Still I can't undesrtand why pg_dump has to know about all the tables?
>>
>> Strictly speaking it probably doesn't need to.  But it is primarily
>> designed for dumping entire databases, and the efficient way to do
>> that is to read it all into memory in a few queries and then sort out
>> the dependencies, rather than tracking down every dependency
>> individually with one or more trips back to the database.  (Although
>> it still does make plenty of trips back to the database per
>> table/sequence, for acls, defaults, attributes.
>>
>> If you were to rewrite pg_dump from the ground up to achieve your
>> specific needs (dumping one schema, with no dependencies between to
>> other schemata) you could probably make it much more efficient.  But
>> then it wouldn't be pg_dump, it would be something else.
>>
>
> Please don't think that I'm trying to nitpick here, but pg_dump has options
> for dumping separate tables and that's not really consistent with the idea
> that "pg_dump is primarily  designed for dumping entire databases".

I think it is compatible.  From my reading of pg_dump, those other
options seem to have been bolted on as an afterthought, not as part of
its primary design.

Cheers,

Jeff


В списке pgsql-performance по дате отправления:

Предыдущее
От: Denis
Дата:
Сообщение: Re: [HACKERS] pg_dump and thousands of schemas
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] pg_dump and thousands of schemas