Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Дата
Msg-id BANLkTi=jcKSU5zR+JG2BvfLNCtezC9sb+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Список pgsql-hackers
On Wed, May 25, 2011 at 9:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, I had been thinking about the latter point.  We could be
> conservative and just keep the reported tuple density the same (ie,
> update relpages to the new correct value, while setting reltuples so
> that the density ratio doesn't change).  But that has its own problems
> when the table contents *do* change.  What I'm currently imagining is
> to do a smoothed moving average, where we factor in the new density
> estimate with a weight dependent on the percentage of the table we did
> scan.  That is, the calculation goes something like
>
> old_density = old_reltuples / old_relpages
> new_density = counted_tuples / scanned_pages
> reliability = scanned_pages / new_relpages
> updated_density = old_density + (new_density - old_density) * reliability
> new_reltuples = updated_density * new_relpages

This amounts to assuming that the pages observed in the vacuum have
the density observed and the pages that weren't seen have the density
that were previously in the reltuples/relpages stats. That seems like
a pretty solid approach to me. If the numbers were sane before it
follows that they should be sane after the update.

--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: SSI predicate locking on heap -- tuple or row?