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 по дате отправления: