On Thu, May 26, 2011 at 1:28 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> I think we should really consider replacing reltuples with
>> reltupledensity at some point. I continue to be afraid that using
>> a decaying average in this case is going to end up overweighting
>> the values from some portion of the table that's getting scanned
>> repeatedly, at the expense of other portions of the table that are
>> not getting scanned at all. Now, perhaps experience will prove
>> that's not a problem. But storing relpages and reltupledensity
>> separately would give us more flexibility, because we could feel
>> free to bump relpages even when we're not sure what to do about
>> reltupledensity. That would help Florian's problem quite a lot,
>> even if we did nothing else.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
