On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote: > "Joel Jacobson" <j...@compiler.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
