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

From Michael Paquier
Subject Re: predefined role(s) for VACUUM and ANALYZE
Date
Msg-id Yyppg/c4SB7s1IAv@paquier.xyz
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
On Tue, Sep 20, 2022 at 04:50:10PM -0700, Nathan Bossart wrote:
> On Tue, Sep 20, 2022 at 04:31:17PM -0700, Nathan Bossart wrote:
>> On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote:
>>> On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
>>>> Any impact for the column sizes of the catalogs holding ACL
>>>> information?  Just asking while browsing the patch set.
>>>
>>> Since each aclitem requires 16 bytes instead of 12, I assume so.  However,
>>> in my testing, I hit a "row is too big" error with the same number of
>>> aclitems in a pg_class row before and after the change.  I might be missing
>>> something in my patch, or maybe I am misunderstanding how arrays of
>>> aclitems are stored on disk.
>>
>> Ah, it looks like relacl is compressed.  The column is marked "extended,"
>> but pg_class doesn't appear to have a TOAST table, so presumably no
>> out-of-line storage can be used.  I found a couple of threads about this
>> [0] [1] [2].

Adding a toast table to pg_class has been a sensitive topic over the
years.  Based on my recollection of the events, there were worries
about the potential cross-dependencies with pg_class and pg_attribute
that this would create.

> I suppose there is some risk that folks with really long aclitem arrays
> might be unable to pg_upgrade to a version with uint64 AclModes, but I
> suspect that risk is limited to extreme cases (i.e., multiple thousands of
> aclitems).  I'm not sure whether that's worth worrying about too much.

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?

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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support pg_attribute_aligned and noreturn in MSVC
Next
From: David Rowley
Date:
Subject: Re: Hash index build performance tweak from sorting