From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Luke Cowell <lcowell(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Possible performance regression with pg_dump of a large number of relations |
Date: | 2018-01-24 22:56:41 |
Message-ID: | 20180124225641.GC2416@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi there!
* Luke Cowell (lcowell(at)gmail(dot)com) wrote:
> Hi Stephen, thank you for putting this together.
Yeah, it needs more work, which I figured out after actually hacking
together a patch for it and I've just not gotten back to it yet.
> > If folks get a chance to take a look at the query and/or test, that'd be
> > great. I'll try to work up an actual patch to pg_dump this weekend to
> > run it through the regression tests and see if anything breaks.
>
> I'm not sure how I can help other than testing that this runs. I can confirm that it runs on 10.1. It does not run on 9.5 or 9.6 and gives this error:
Thanks for offering to help! Once I've got an actual patch together
that works well enough to get through the regression tests, I'll
definitely let you know. The general premise still looks viable, but
the actual query needs to be reworked.
> > ERROR: relation "pg_init_privs" does not exist
> > LINE 139: LEFT JOIN pg_init_privs pip
I certainly hope that works on 9.6, since that's when pg_init_privs was
added..
> I'm guessing that the error is not surprising and that the query is intended for an upcoming release of postgres and wouldn't be backported to 9.6.x
Presuming I can make it work, the idea would be to back-port it to 9.6
and 10, since pg_init_privs and this code was added in 9.6.
Thanks again!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-01-24 23:10:06 | reducing isolation tests runtime |
Previous Message | Tom Lane | 2018-01-24 22:52:47 | Re: Converting plpgsql to use DTYPE_REC for named composite types |