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
