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

From Amit Langote
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id 5654275B.2080804@lab.ntt.co.jp
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015/11/21 5:46, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 2:18 AM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> As someone pointed out upthread, the final heap truncate phase can take
>> arbitrarily long and is outside the scope of lazy_scan_heap() to
>> instrument. Perhaps a bool, say, waiting_heap_trunc could be reported for
>> the same. Note that, it would have to be reported from lazy_vacuum_rel().
> 
> I don't think reporting booleans is a very good idea.  It's better to
> report that some other way, like use one of the strings to report a
> "phase" of processing that we're currently performing.

Yeah, that might be better. One possible downside of booleans I didn't
foresee is that too many of them might clutter the progress view. What
would've been the names of boolean columns in the progress view are better
reported as strings as the value of a single column, as you seem to suggest.

> 
>> IMHO, float progress parameters (st_progress_param_float[]) can be taken
>> out. They are currently unused and it's unlikely that some command would
>> want to report them.
> 
> If they are not used, they shouldn't be included in this patch, but we
> should be open to adding them later if it proves useful.

Certainly.

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Marco Nenciarini
Date:
Subject: Re: pg_receivexlog: spurious error message connecting to 9.3