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

From Jim Nasby
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id 55D2BF78.8010205@BlueTreble.com
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Rahila Syed <rahilasyed90@gmail.com>)
List pgsql-hackers
On 8/17/15 5:07 PM, Rahila Syed wrote:
>>In case ofvacuum, I think we need to track the number of scanned heap
>>pages at least, and the information about index scan is the additional
>>information
>
> Actually the progress of heap pages scan depend on index scans. So
> complete VACUUM progress
> needs to have a count of index pages scanned too. So, progress can be
> calculated by measuring index_pages_scanned + heap_pages_scanned
> against total_index_pages + total_heap_pages. This can make essential
> information.

There's absolutely no way to get a reasonable status report in the case 
of multiple index passes unless you somehow count the passes, especially 
since index cleanup is frequently MUCH longer than the heap cleanup.

What should work is exporting the number of index passes we've already 
made. If > 0 we know we're in a multiple scan situation. At the end of 
each index pass, do index_passes++; index_pages=0; index_pages_scanned=0.

Personally, I think we should use SIGINFO to signal a backend to output 
status data to a file in pg_stat_tmp/ (but not the main stats file) and 
be done with it. That allows us to easily handle variable length stuff 
with minimal fuss. No normal user is going to hammer away at that, and 
anyone that's really worried about performance will have that directory 
sitting on a ramdisk anyway.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Kaare Rasmussen
Date:
Subject: Re: jsonb array-style subscripting
Next
From: Michael Paquier
Date:
Subject: Re: missing documentation for partial WAL files