Re: [PROPOSAL] VACUUM Progress Checker.

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [PROPOSAL] VACUUM Progress Checker.
Дата
Msg-id 20150810165017.GE2441@postgresql.org
обсуждение исходный текст
Ответ на Re: [PROPOSAL] VACUUM Progress Checker.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [PROPOSAL] VACUUM Progress Checker.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: [PROPOSAL] VACUUM Progress Checker.  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Masahiko Sawada wrote:

> This topic may have been already discussed but, why don't we use just
> total scanned pages and total pages?

Because those numbers don't extrapolate nicely.  If the density of dead
tuples is irregular across the table, such absolute numbers might be
completely meaningless: you could scan 90% of the table without seeing
any index scan, and then at the final 10% be hit by many index scans
cleaning dead tuples.  Thus you would see progress go up to 90% very
quickly and then take hours to have it go to 91%.  (Additionally, and a
comparatively minor point: since you don't know how many index scans are
going to happen, there's no way to know the total number of blocks
scanned, unless you don't count index blocks at all, and then the
numbers become a lie.)

If you instead track number of heap pages separately from index pages,
and indicate how many index scans have taken place, you have a chance of
actually figuring out how many heap pages are left to scan and how many
more index scans will occur.

> The mechanism of VACUUM is complicated a bit today,

Understatement of the week ...

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Geoff Winkless
Дата:
Сообщение: Re: Precedence of standard comparison operators
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Rework access method interface