Re: [PATCH] pg_permissions

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: [PATCH] pg_permissions
Дата
Msg-id ab5e5226-2175-488b-8cec-3f91f86a0542@www.fastmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] pg_permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: WIP: BRIN multi-range indexes
Следующее
От: Pantelis Theodosiou
Дата:
Сообщение: Re: Idea: Avoid JOINs by using path expressions to follow FKs