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 CAGTBQpYdNN_Q3Ksvr7tN_6aXqp_gc0KOsbrWLW_QZE=c22QjUg@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORM] pg_dump and thousands of schemas  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, May 31, 2012 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The performance patches we applied to pg_dump over the past couple weeks
> were meant to relieve pain in situations where the big server-side
> lossage wasn't the dominant factor in runtime (ie, partial dumps).
> But this one is targeting exactly that area, which is why it looks like
> a band-aid and not a fix to me.

No, Tatsuo's patch attacks a phase dominated by latency in some
setups. That it's also becoming slow currently because of the locking
cost is irrelevant, with locking sped up, the patch should only
improve the phase even further. Imagine the current timeline:

* = locking
. = waiting

*.*.**.**.***.***.****.****.*****.****

Tatsuo's patch converts it to:

*.**************

The locking fix would turn the timeline into:

*.*.*.*.*.*.*

Tatsuo's patch would turn that into:

*******

And, as noted before, pg_dump --schema-only is a key bottleneck in pg_upgrade.

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PERFORM] pg_dump and thousands of schemas
Next
From: Robert Haas
Date:
Subject: Re: [PERFORM] pg_dump and thousands of schemas