Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Given how trivial it would be to adjust reltuples to keep its
>> ratio to relpages about the same when we don't have a new "hard"
>> number, but some evidence that we should fudge our previous
>> value, I don't see where this change buys us much. It seems to
>> mostly obfuscate the fact that we're changing our assumption
>> about how many tuples we have. I would rather that we did that
>> explicitly with code comments about why it's justified than to
>> slip it in the way you suggest.
>
> I'm a bit confused by this - what the current design obfuscates is
> the fact that reltuples and relpages are not really independent
> columns; you can't update one without updating the other, unless
> you want screwy behavior. Replacing reltuples by reltupledensity
> would fix that problem - it would be logical and non-damaging to
> update either column independently.
They don't always move in tandem. Certainly there can be available
space in those pages from which tuples can be allocated or which
increases as tuples are vacuumed. Your proposed change would
neither make more or less information available, because we've got
two numbers which can be observed as raw counts, and a ratio between
them. By storing the ratio and one count you make changes to the
other count implied and less visible. It seems more understandable
and less prone to error (to me, anyway) to keep the two "raw"
numbers and calculate the ratio -- and when you observe a change in
one raw number which you believe should force an adjustment to the
other raw number before its next actual value is observed, to
comment on why that's a good idea, and do the trivial arithmetic at
that time.
As a thought exercise, what happens each way if a table is loaded
with a low fillfactor and then a lot of inserts are done? What
happens if mass deletes are done from a table which has a high
density?
-Kevin