On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
> 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
