Re: [PROPOSAL] VACUUM Progress Checker.

From: "Syed, Rahila" <Rahila(dot)Syed(at)nttdata(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Date: 2015-08-13 10:12:04
Message-ID: C3C878A2070C994B9AE61077D46C38468815EFFE@MAIL703.KDS.KEANE.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 need for 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 need to scan.

Total heap pages to be scanned can be obtained from VM as mentioned. To figure out number of index scans we need an estimate of 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 adding number 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2015-08-13 11:08:16 Re: Our trial to TPC-DS but optimizer made unreasonable plan
Previous Message Andres Freund 2015-08-13 09:38:37 Re: [COMMITTERS] pgsql: Close some holes in BRIN page assignment