Re: Save a few bytes in pg_attribute

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Save a few bytes in pg_attribute
Date: 2023-03-20 17:46:06
Message-ID: 09ce1c98-bb98-d374-09b3-50e61e2e29f5@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/20/23 15:37, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>> After the discussion in [0] ff., I was looking around in pg_attribute
>> and noticed that we could possibly save 4 bytes. We could change both
>> attstattarget and attinhcount from int4 to int2, which together with
>> some reordering would save 4 bytes from the fixed portion.
>
>> attstattarget is already limited to 10000, so this wouldn't lose
>> anything. For attinhcount, I don't see any documented limits. But it
>> seems unlikely to me that someone would need more than 32k immediate
>> inheritance parents on a column. (Maybe an overflow check would be
>> useful, though, to prevent shenanigans.)
>
>> The attached patch seems to work. Thoughts?
>
> I agree that attinhcount could be narrowed, but I have some concern
> about attstattarget. IIRC, the limit on attstattarget was once 1000
> and then we raised it to 10000. Is it inconceivable that we might
> want to raise it to 100000 someday?
>

Yeah, I don't think it'd be wise to make it harder to increase the
statistics target limit.

IMHO it'd be much better to just not store the statistics target for
attributes that have it default (which we now identify by -1), or for
system attributes (where we store 0). I'd bet vast majority of systems
will just use the default / GUC value. So if we're interested in saving
these bytes, we could just store NULL in these cases, no?

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark (as CFM) 2023-03-20 17:46:51 Re: Error "initial slot snapshot too large" in create replication slot
Previous Message Tom Lane 2023-03-20 17:43:26 Re: pg_dump needs SELECT privileges on irrelevant extension table