Re: [PROPOSAL] VACUUM Progress Checker.

Поиск
Список
Период
Сортировка
От Syed, Rahila
Тема Re: [PROPOSAL] VACUUM Progress Checker.
Дата
Msg-id C3C878A2070C994B9AE61077D46C38468815EFFE@MAIL703.KDS.KEANE.COM
обсуждение исходный текст
Ответ на Re: [PROPOSAL] VACUUM Progress Checker.  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Hello,

>Autovacuum knows what % of a table needs to be cleaned - that is how it is triggered.
>When a vacuum runs we should calculate how many TIDs we will collect and therefore how many trips to the indexes we
needfor given memory. 
>We can use the VM to find out how many blocks we'll need to scan in the table. So overall, we know how many blocks we
needto scan. 

Total heap pages to be scanned can be obtained from VM as mentioned. To figure out number of index scans we need an
estimateof dead tuples.  

IIUC, autovacuum acquires information that a table has to be cleaned by looking at pgstat entry for the table. i.e
n_dead_tuples.
Hence,initial estimate of dead tuple TIDs can be made using n_dead_tuples in pgstat.
n_dead_tuples in pgstat table entry is the value  updated by last analyze and may not be up to date.
In cases where pgstat entry for table is NULL, number of dead tuples TIDs cannot be estimated.
In  such cases where TIDs cannot be estimated , we can start with an initial estimate of 1 index scan and later go on
addingnumber of index pages to the total count of pages(heap+index)  if count of index scan exceeds. 

Thank you,
Rahila Syed.


______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Close some holes in BRIN page assignment
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Our trial to TPC-DS but optimizer made unreasonable plan