On Wed, Sep 21, 2022 at 10:31:47AM +0900, Michael Paquier wrote:
> Did you just run an aclupdate()? 4% for aclitem[] sounds like quite a
> number to me :/ It may be worth looking at if these operations could
> be locally optimized more, as well. I'd like to think that we could
> live with that to free up enough bits in AclItems for the next 20
> years, anyway. Any opinions?
Yes, the test was mostly for aclupdate(). Looking at that function, I bet
most of its time is spent in palloc0() and memcpy(). It might be possible
to replace the linear search if the array was sorted, but I'm skeptical
that will help much. In the end, I'm not it's worth worrying too much
about 2,000 calls to aclupdate() with an array of 2,000 ACLs taking 5.3
seconds instead of 5.1 seconds.
I bet a more pressing concern is the calls to aclmask() since checking
privileges is probably done more frequently than updating them. That
appears to use a linear search, too, so maybe sorting the aclitem arrays is
actually worth exploring. I still doubt there will be much noticeable
impact from expanding AclMode outside of the most extreme cases.
> For the column sizes of the catalogs, I was wondering about how
> pg_column_size() changes when they hold ACL information. Unoptimized
> alignment could cause an unnecessary increase in the structure sizes,
> so the addition of new fields or changes in object size could have
> unexpected side effects.
After a few tests, I haven't discovered any changes to the output of
pg_column_size().
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
