Re: [PROPOSAL] VACUUM Progress Checker.
От | Robert Haas |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | CA+TgmoYoa+AOLN+m=XGc1_70SvxT1_iBxcMdg72rUOndki=kUg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: [PROPOSAL] VACUUM Progress Checker.
|
Список | pgsql-hackers |
On Thu, Jan 28, 2016 at 8:41 AM, Amit Langote <amitlangote09@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
В списке pgsql-hackers по дате отправления: