On 3/20/23 15:37, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.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