Re: [PERFORM] pg_dump and thousands of schemas - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: [PERFORM] pg_dump and thousands of schemas
Date
Msg-id CAGTBQpZGTipeXBA50ppDp-1CFJFzWDr17mMit9EBJBKOYBGpWA@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Next
From: Peter Geoghegan
Date:
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)