Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> 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?
Hmm, we'd have to move it to the nullable part of the row and expend
more code to fetch it; but I don't think it's touched in many places,
so that might be a good tradeoff. Couple of notes:
* As things stand I think we have a null bitmap in every row of
pg_attribute already (surely attfdwoptions and attmissingval are never
both filled), so there's no extra cost there.
* Putting it in the variable part of the row means it wouldn't appear
in tuple descriptors, but that seems fine.
I wonder if the same is true of attinhcount. Since it's nonzero for
partitions' attributes, it might be non-null in a fairly large fraction
of pg_attribute rows in some use-cases, but it still seems like we'd not
be losing anything. It wouldn't need to be touched in any
high-performance code paths AFAICS.
regards, tom lane
