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. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
