Re: predefined role(s) for VACUUM and ANALYZE - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: predefined role(s) for VACUUM and ANALYZE
Date
Msg-id CAOuzzgpQtdqj2BfwheD9+fjUnVSo1cmdrQmwcr-qbvKjC5cfyg@mail.gmail.com
Whole thread Raw
In response to Re: predefined role(s) for VACUUM and ANALYZE  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: predefined role(s) for VACUUM and ANALYZE
List pgsql-hackers
Greetings,

On Wed, Sep 28, 2022 at 14:50 Nathan Bossart <nathandbossart@gmail.com> wrote:
On Tue, Sep 20, 2022 at 09:31:26PM -0700, Nathan Bossart wrote:
> 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.

I've been testing aclmask() with long aclitem arrays (2,000 entries is
close to the limit for pg_class entries), and I haven't found any
significant impact from bumping AclMode to 64 bits.

The max is the same regardless of the size..?  Considering the size is capped since pg_class doesn’t (and isn’t likely to..) have a toast table, that seems unlikely, so I’m asking for clarification on that. We may be able to get consensus that the difference isn’t material since no one is likely to have such long lists, but we should at least be aware.

Thanks,

Stephen

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: predefined role(s) for VACUUM and ANALYZE
Next
From: Alvaro Herrera
Date:
Subject: Re: longfin and tamandua aren't too happy but I'm not sure why