Re: [PERFORM] pg_dump and thousands of schemas

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: [PERFORM] pg_dump and thousands of schemas
Дата
Msg-id CAGTBQpZGTipeXBA50ppDp-1CFJFzWDr17mMit9EBJBKOYBGpWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, May 31, 2012 at 12:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No, Tatsuo's patch attacks a phase dominated by latency in some
>> setups.
>
> No, it does not.  The reason it's a win is that it avoids the O(N^2)
> behavior in the server.  Whether the bandwidth savings is worth worrying
> about cannot be proven one way or the other as long as that elephant
> is in the room.
>
>                        regards, tom lane

I understand that, but if the locking is fixed and made to be O(N)
(and hence each table locking O(1)), then latency suddenly becomes the
dominating factor.

I'm thinking, though, pg_upgrade runs locally, contrary to pg_dump
backups, so in that case latency would be negligible and Tatsuo's
patch inconsequential.

I'm also thinking, whether the ResourceOwner patch you've proposed
would get negated by Tatsuo's patch, because suddenly a "portal"
(IIRC) has a lot more locks than ResourceOwner could accomodate,
forcing a reversal to O(N²) behavior. In that case, that patch would
in fact be detrimental... huh... way to go 180

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)