On Thu, May 26, 2011 at 1:28 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
