Re: Statistics mismatch between n_live_tup and actual row count
От
Tom Lane
Тема
Re: Statistics mismatch between n_live_tup and actual row count
Дата
Msg-id
10296.1354850362@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Re: Statistics mismatch between n_live_tup and actual row count Tom Lane <tgl@sss.pgh.pa.us>
Re: Statistics mismatch between n_live_tup and actual row count tim_wilson <tim.wilson@telogis.com>
Re: Statistics mismatch between n_live_tup and actual row count Tom Lane <tgl@sss.pgh.pa.us>
Re: Statistics mismatch between n_live_tup and actual row count tim_wilson <tim.wilson@telogis.com>
tim_wilson writes: > This drift gets more confusing. In recent releases, reltuples (and relpages) are updated via a "moving average" calculation that is meant to converge on the true value over time. The reason vacuum has to act that way is that it typically doesn't scan the whole table anymore, but only the pages that have been dirtied recently. So it measures the tuple density in the pages it scans, and updates the previous value more or less aggressively depending on the percentage of the pages that it looked at. It's possible that there's some bug in that algorithm, but what seems more likely is that the pages that are getting dirtied are nonrepresentative of the whole table for some reason. Or maybe both. Can you put together a self-contained test case showing this behavior? regards, tom lane
В списке pgsql-general по дате отправления
От: tim_wilson
Дата: