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

From Noah Misch
Subject Re: pg_dump dump catalog ACLs
Date
Msg-id 20160504234705.GA2428510@tornado.leadboat.com
Whole thread Raw
In response to Re: pg_dump dump catalog ACLs  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_dump dump catalog ACLs
List pgsql-hackers
On Wed, May 04, 2016 at 08:14:55AM -0400, Stephen Frost wrote:
> * Noah Misch (noah@leadboat.com) wrote:
> > On Mon, Apr 25, 2016 at 12:39:09AM -0400, Stephen Frost wrote:
> > > * Noah Misch (noah@leadboat.com) wrote:
> > > > On Fri, Apr 22, 2016 at 12:31:41PM -0400, Stephen Frost wrote:
> > > > > After looking through the code a bit, I realized that there are a lot of
> > > > > object types which don't have ACLs at all but which exist in pg_catalog
> > > > > and were being analyzed because the bitmask for pg_catalog included ACLs
> > > > > and therefore was non-zero.
> > > > > 
> > > > > Clearing that bit for object types which don't have ACLs improved the
> > > > > performance for empty databases quite a bit (from about 3s to a bit
> > > > > under 1s on my laptop).  That's a 42-line patch, with comment lines
> > > > > being half of that, which I'll push once I've looked into the other
> > > > > concerns which were brought up on this thread.
> > > > 
> > > > That's good news.
> > > 
> > > Attached patch-set includes this change in patch #2.
> > 
> > Timings for the 100-database pg_dumpall:
> > 
> > HEAD:        131s
> > HEAD+patch:  33s
> > 9.5:          8.6s
> > 
> > Nice improvement for such a simple patch.
> 
> Patch #2 in the attached patchset includes that improvement and a
> further one which returns the performance to very close to 9.5.

What timings did you measure?  (How close?)



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: what to revert
Next
From: Stephen Frost
Date:
Subject: Re: pg_dump broken for non-super user