On Thu, May 26, 2011 at 12:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Another thought: Couldn't relation_needs_vacanalyze() just scale up >> reltuples by the ratio of the current number of pages in the relation >> to relpages, just as the query planner does? > > Hmm ... that would fix Florian's immediate issue, and it does seem like > a good change on its own merits. But it does nothing for the problem > that we're failing to put the best available information into pg_class. > > Possibly we could compromise on doing just that much in the back > branches, and the larger change for 9.1?
Do you think we need to worry about the extra overhead of determining the current size of every relation as we sweep through pg_class? It's not a lot, but OTOH I think we'd be doing it once a minute... not sure what would happen if there were tons of tables. Going back to your thought upthread, 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. -- 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
