Re: [PROPOSAL] VACUUM Progress Checker. - Mailing list pgsql-hackers

From Syed, Rahila
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id C3C878A2070C994B9AE61077D46C384688831DB9@MAIL703.KDS.KEANE.COM
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Rahila Syed <rahilasyed90@gmail.com>)
Responses Re: [PROPOSAL] VACUUM Progress Checker.  (Thom Brown <thom@linux.com>)
Re: [PROPOSAL] VACUUM Progress Checker.  (Thom Brown <thom@linux.com>)
List pgsql-hackers
Hello,

Please find attached updated VACUUM progress checker patch.
Following have been accomplished in the patch

1. Accounts for index pages count while calculating  total progress of VACUUM.
2. Common location for storing progress parameters for any command. Idea is every command which needs to report
progresscan populate and interpret the shared variables in its own way. 
     Each can display progress by implementing separate views.
3. Separate VACUUM progress view to display various progress parameters has been implemented . Progress of various
phaseslike heap scan, index scan, total pages scanned along with  
    completion percentage is reported.
4.This view can display progress for all active backends running VACUUM.

Basic testing has been performed. Thorough testing is yet to be done. Marking it as Needs Review in  Sept-Commitfest.

ToDo:
Display count of heap pages actually vacuumed(marking line pointers unused)
Display percentage of work_mem being used to store dead tuples.

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.

Attachment

pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Double linking MemoryContext children
Next
From: Robert Haas
Date:
Subject: Re: Latent cache flush hazard in RelationInitIndexAccessInfo