Re: [PROPOSAL] VACUUM Progress Checker.

From: <pokurev(at)pm(dot)nttdata(dot)co(dot)jp>
To: <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: <pgsql-hackers(at)postgresql(dot)org>, <bannos(at)nttdata(dot)co(dot)jp>
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Date: 2016-02-26 08:28:13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


Thank you for your comments.
Please find attached patch addressing following comments.

>As I might have written upthread, transferring the whole string
>as a progress message is useless at least in this scenario. Since
>they are a set of fixed messages, each of them can be represented
>by an identifier, an integer number. I don't see a reason for
>sending the whole of a string beyond a backend.
Agreed. I used following macros.

>I guess num_index_scans could better be reported after all the indexes are
>done, that is, after the for loop ends.
Agreed. I have corrected it.

> CREATE VIEW pg_stat_vacuum_progress AS
> SELECT S.s[1] as pid,
> S.s[2] as relid,
> CASE S.s[3]
> WHEN 1 THEN 'Scanning Heap'
> WHEN 2 THEN 'Vacuuming Index and Heap'
> ELSE 'Unknown phase'
> END,
> ....
> FROM pg_stat_get_command_progress(PROGRESS_COMMAND_VACUUM) as S;
> # The name of the function could be other than *_command_progress.
The name of function is updated as pg_stat_get_progress_info() and also updated the function.
Updated the pg_stat_vacuum_progress view as suggested.


Attachment Content-Type Size
Vacuum_progress_checker_v12.patch application/octet-stream 22.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2016-02-26 09:19:12 Re: [PROPOSAL] VACUUM Progress Checker.
Previous Message Kyotaro HORIGUCHI 2016-02-26 07:37:46 Re: IF (NOT) EXISTS in psql-completion