Re: [PROPOSAL] VACUUM Progress Checker.

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: "Syed, Rahila" <Rahila(dot)Syed(at)nttdata(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Date: 2015-08-10 15:59:36
Message-ID: CAD21AoA+ubpwhK6Z=Fi8qvkAhzMG0JnzjFda17tfDLzOuCVNNQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 11, 2015 at 12:20 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 10 August 2015 at 15:59, Syed, Rahila <Rahila(dot)Syed(at)nttdata(dot)com> wrote:
>>
>> Hello,
>>
>> >When we're in Phase2 or 3, don't we need to report the number of total
>> > page scanned or percentage of how many table pages scanned, as well?
>> The total heap pages scanned need to be reported with phase 2 or 3.
>> Complete progress report need to have numbers from each phase when
>> applicable.
>>
>> > Phase 1. Report 2 integer counters: heap pages scanned and total heap
>> > pages,
>> > 1 float counter: percentage_complete and progress message.
>> > Phase 2. Report 2 integer counters: index pages scanned and total
>> > index pages(across all indexes) and progress message.
>> > Phase 3. 1 integer counter: heap pages vacuumed.
>>
>> Sorry for being unclear here. What I meant to say is, each phase of a
>> command will correspond to a slot in COMMAND_NUM_SLOTS. Each phase will be a
>> separate array element and
>> will comprise of n integers, n floats, string. So , in the view reporting
>> progress, VACUUM command can have 3 entries one for each phase.
>
>
> VACUUM has 3 phases now, but since phases 2 and 3 repeat, you can have an
> unbounded number of phases. But that assumes that we don't count truncation
> as a 4th phase of VACUUM...

Yeah.
This topic may have been already discussed but, why don't we use just
total scanned pages and total pages?

The mechanism of VACUUM is complicated a bit today, and other
maintenance command is as well.
It would be tough to trace these processing, and these might be
changed in the future.
But basically, we can trace total scanned pages of target relation
easily, and such information would be enough at many case.

Regards,

--
Masahiko Sawada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2015-08-10 16:04:26 Re: WIP: Rework access method interface
Previous Message Alexander Korotkov 2015-08-10 15:53:27 Re: WIP: Rework access method interface