[go: up one dir, main page]

Re: predefined role(s) for VACUUM and ANALYZE

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: predefined role(s) for VACUUM and ANALYZE
Date: 2022-09-21 01:31:47
Message-ID: Yyppg/c4SB7s1IAv@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to Responses Browse pgsql-hackers by date
  From Date Subject
Next Message David Rowley 2022-09-21 01:31:52 Re: Hash index build performance tweak from sorting
Previous Message Michael Paquier 2022-09-21 01:17:56 Re: Support pg_attribute_aligned and noreturn in MSVC