Re: [PATCH] pg_permissions

On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
> "Joel Jacobson" <joel(at)compiler(dot)org <mailto:joel%40compiler.org>> writes:
> > On Thu, Mar 25, 2021, at 16:16, Alvaro Herrera wrote:
> >> Ah, of course -- the only way to obtain the acl columns is by going
> >> through the catalogs individually, so it won't be possible. I think
> >> this could be fixed with some very simple, quick function pg_get_acl()
> >> that takes a catalog OID and object OID and returns the ACL; then
> >> use aclexplode() to obtain all those details.
>
> > +1 for adding pg_get_acl().
>
> I wonder what performance will be like with lots o' objects.

I guess pg_get_acl() would need to be implemented using a switch(classid) with 36 cases (one for each class)?

Is your performance concern on how such switch statement will be optimized by the C-compiler?

I can see how it would be annoyingly slow if the compiler would pick a branch table or binary search,
instead of producing a O(2) fast jump table.

On the topic of C switch statements:

I think the Clang/GCC-compiler folks (anyone here?) could actually be inspired by PostgreSQL's PerfectHash.pm.
I think the same strategy could be used in C compilers to optimize switch statements with sparse case values,
which currently produce slow binary search code O(log n) while a perfect hash solution would be O(2).

Example showing the unintelligent binary search code produced by GCC: https://godbolt.org/z/1G6G3vcjx (Clang is just as bad.) This is a hypothetical example with sparse case values. This is not the case here, since the classid case values are nicely ordered from OCLASS_CLASS..OCLASS_TRANSFORM (0..37), so they should produce O(2) fast jump tables.

Maybe there is some other performance concern to reason about that I'm missing here?

/Joel