On Thu, Jan 28, 2016 at 8:41 AM, Amit Langote <amitlangot...@gmail.com> wrote: > Or keep scanned_heap_pages as is and add a skipped_pages (or > skipped_heap_pages). I guess the latter would be updated not only for > all visible skipped pages but also pin skipped pages. That is, > updating its counter right after vacrelstats->pinskipped_pages++ which > there are a couple of instances of. Likewise a good (and only?) time > to update the former's counter would be right after > vacrelstats->scanned_pages++. Although, I see at least one place where > both are incremented so maybe I'm not entirely correct about the last > two sentences.
So I've spent a fair amount of time debugging really-long-running VACUUM processes with customers, and generally what I really want to know is: >>> What block number are we at? <<< Because, if I know that, and I can see how fast that's increasing, then I can estimate whether the VACUUM is going to end in a reasonable period of time or not. So my preference is to not bother breaking out skipped pages, but just report the block number and call it good. I will defer to a strong consensus on something else, but reporting the block number has the advantage of being dead simple and, in my experience, that would answer the question that I typically have. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
