Tomas Vondra <tomas.von...@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