Re: [PATCH] pg_permissions - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: [PATCH] pg_permissions
Date
Msg-id ab5e5226-2175-488b-8cec-3f91f86a0542@www.fastmail.com
Whole thread Raw
In response to Re: [PATCH] pg_permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Mar 26, 2021, at 14:16, Tom Lane wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Mar-26, Joel Jacobson wrote:
>> On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
>> I wonder what performance will be like with lots o' objects.

> I guess he is concerned about the number of catalog accesses.

My concern is basically that you're forcing the join between
pg_shdepend and $everything_else to be done as a nested loop.
It will work well, up to where you have so many objects that
it doesn't ... but the planner will have no way to improve it.

Thanks Alvaro and Tom for explaining.

Having said that, I don't really see a better way either.
Materializing $everything_else via a UNION ALL seems like
no fun from a maintenance perspective, plus we're not that
great on optimizing such constructs either.

I see why pg_shdepend+pg_get_acl() is to prefer.

That said, I think maintenance of UNION ALL would actually not be too bad,
since the system views could initially be generated by a query using information_schema,
and the same query could update them when new catalogs are added.

/Joel

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes
Next
From: Pantelis Theodosiou
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs