Tom Lane wrote: > This patch was originally submitted before we realized that pg_stats > failed to distinguish the effects of committed vs rolled-back > transactions (which was fixed about three months ago); and we also > recently fixed several other bugs such as losing stats data for shared > catalogs. So there's a significant probability that the errors it was > trying to compensate for are already fixed.
Quite possible. I don't recall a real world example or a test case preceding the patch. I guess the problem scenario would be a table with a lot of update/delete activity, and very unaggressive cost_delay. > Also, I'm still quite unhappy that the patch converts the tracking of > n_dead_tuples into a dead-reckoning system in which incremental changes > are continually applied without any feedback that'd prevent the value > from diverging arbitrarily far from reality. Murphy's law says that > the value *will* diverge, if you don't have any negative feedback > in the loop to force it to track reality. I believe the latest version doesn't have that problem. At the beginning of vacuum, n_dead_tuples is saved, and at the end of vacuum n_dead_tuples is decremented by the value it had at the beginning. At the end n_dead_tuples will be equal to the number of new dead tuples generated during the vacuum, no matter how out of whack it was in the beginning. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
