Re: pg_dump dump catalog ACLs - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pg_dump dump catalog ACLs
Date
Msg-id CAOuzzgrZKA8pzyaOP5mBXdvSpKUex0Bc2e7zt7ZaMHiSTOR1_Q@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump dump catalog ACLs  (Noah Misch <noah@leadboat.com>)
Responses Re: pg_dump dump catalog ACLs  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah,

On Wednesday, April 20, 2016, Noah Misch <noah@leadboat.com> wrote:
On Wed, Apr 20, 2016 at 11:12:44AM -0400, Stephen Frost wrote:
> * Noah Misch (noah@leadboat.com) wrote:
> > On Sun, Apr 17, 2016 at 11:02:28PM -0400, Noah Misch wrote:
> > > (3) pg_dumpall became much slower around the time of these commits.  On one
> > > machine (POWER7 3.55 GHz), a pg_dumpall just after initdb slowed from 0.25s at
> > > commit 6c268df^ to 4.0s at commit 7a54270.  On a slower machine (Opteron
> > > 1210), pg_dumpall now takes 19s against such a fresh cluster.
> >
> > [This is a generic notification.]
> >
> > The above-described topic is currently a PostgreSQL 9.6 open item.  Stephen,
> > since you committed the patch believed to have created it, you own this open
> > item.  If that responsibility lies elsewhere, please let us know whose
> > responsibility it is to fix this.  Since new open items may be discovered at
> > any time and I want to plan to have them all fixed well in advance of the ship
> > date, I will appreciate your efforts toward speedy resolution.  Please
> > present, within 72 hours, a plan to fix the defect within seven days of this
> > message.  Thanks.
>
> I'm at PGConf.US but will be reviewing this in detail after.  The schema
> qualification will be easily taken care of, the additional time for
> pg_dump is due to the queries looking at the catalog objects and is
> therefore relatively fixed and is primairly only a large amount of the
> time when dumping databases which are mostly empty.

Do you think it would be okay to release 9.6 with pg_dump still adding that
amount of time per database?

For my 2c, the answer is "yes". I've actually looked at how this could be improved using a bit of caching in pg_dump for certain things, but I didn't think those would be appropriate to include in this patch and would be a general pg_dump performance improvement.  

I'm certainly open to improving these issues now if we agree that they should be fixed for 9.6.  If we don't want to include such changes in 9.6 then I will propose then for post-9.6. 

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: EXPLAIN VERBOSE with parallel Aggregate
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pg_stat_activity crashes