Re: progress report for ANALYZE - Mailing list pgsql-hackers

From Tatsuro Yamada
Subject Re: progress report for ANALYZE
Date
Msg-id 244cb241-168b-d6a9-c45f-a80c34cdc6ad@nttcom.co.jp
Whole thread Raw
In response to Re: progress report for ANALYZE  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: progress report for ANALYZE  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Hi Alvaro, Anthony, Julien and Robert,

On 2019/07/09 3:47, Julien Rouhaud wrote:
> On Mon, Jul 8, 2019 at 8:44 PM Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Mon, Jul 8, 2019 at 2:18 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>> Yeah, I got the impression that that was determined to be the desirable
>>> behavior, so I made it do that, but I'm not really happy about it
>>> either.  We're not too late to change the CREATE INDEX behavior, but
>>> let's discuss what is it that we want.
>>
>> I don't think I intended to make any such determination -- which
>> commit do you think established this as the canonical behavior?
>>
>> I propose that once a field is set, we should leave it set until the end.
> 
> +1
> 
> Note that this patch is already behaving like that if the table only
> contains dead rows.


I fixed the patch including:

   - Replace "if" to "else if". (Suggested by Julien)
   - Fix typo s/ech/each/. (Suggested by Anthony)
   - Add Phase "analyzing complete" in the pgstat view. (Suggested by Julien, Robert and me)
     It was overlooked to add it in system_views.sql.

I share my re-test result, see below:

---------------------------------------------------------
[Session #1]
create table hoge as select * from generate_series(1, 1000000) a;
analyze verbose hoge;

[Session #2]
\a \t
select * from pg_stat_progress_analyze; \watch 0.001

3785|13599|postgres|16384|f|16384|scanning table|4425|6
3785|13599|postgres|16384|f|16384|scanning table|4425|31
3785|13599|postgres|16384|f|16384|scanning table|4425|70
3785|13599|postgres|16384|f|16384|scanning table|4425|109
...
3785|13599|postgres|16384|f|16384|scanning table|4425|4425
3785|13599|postgres|16384|f|16384|scanning table|4425|4425
3785|13599|postgres|16384|f|16384|scanning table|4425|4425
3785|13599|postgres|16384|f|16384|analyzing sample|0|0
3785|13599|postgres|16384|f|16384|analyzing complete|0|0 <-- Added and fixed. :)
---------------------------------------------------------

Thanks,
Tatsuro Yamada




Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Tomas Vondra
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)