Re: [HACKERS] CLUSTER command progress monitor

From: Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tattsu Yama <yamatattsu(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, robertmhaas(at)gmail(dot)com, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers(at)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: [HACKERS] CLUSTER command progress monitor
Date: 2019-09-17 03:30:12
Message-ID: ed16bb3b-c7c9-b304-5a6a-c27aa008f665@nttcom.co.jp_1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alvaro!

>>>> Is this fix strictly necessary for pg12, or is this something that we
>>>> can leave for pg13?
>>>
>>> Not only me but many DBA needs this progress report feature on PG12,
>>> therefore I'm trying to fix the problem. If you send other patch to
>>> fix the problem, and it is more elegant than mine, I can withdraw my patch.
>>> Anyway, I want to avoid this feature being reverted.
>>> Do you have any ideas to fix the problem?
>>
>> I committed a fix for the originally reported problem as da47e43dc32e in
>> branch REL_12_STABLE.  Is that insufficient, and if so why?
>
>
> Ooops, I misunderstood. I now realized you committed your patch to
> fix the problem. Thanks! I'll test it later. :)
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=da47e43dc32e3c5916396f0cbcfa974b371e4875

I tested your patch (da47e43d) and it works fine. Thanks! :)
So, my patch improving progress reporting API can leave for PG13.

#Test scenario
===================
[Session #1]
select * from pg_stat_progress_cluster ; \watch 0.0001

[Session #2]
create table hoge as select a from generate_series(1, 100000) a;
create index ind_hoge1 on hoge(a);
create index ind_hoge2 on hoge((a%2));
create index ind_hoge3 on hoge((a%3));
create index ind_hoge4 on hoge((a%4));
create index ind_hoge5 on hoge((a%5));
cluster hoge using ind_hoge1;
===================

#Test result
===================
22283|13593|postgres|16384|CLUSTER|initializing|0|0|0|0|0|0
...
22283|13593|postgres|16384|CLUSTER|rebuilding index|16387|100000|100000|0|0|0 <= Increasing from 0 to 5
22283|13593|postgres|16384|CLUSTER|rebuilding index|16387|100000|100000|0|0|1
22283|13593|postgres|16384|CLUSTER|rebuilding index|16387|100000|100000|0|0|2
22283|13593|postgres|16384|CLUSTER|rebuilding index|16387|100000|100000|0|0|3
22283|13593|postgres|16384|CLUSTER|rebuilding index|16387|100000|100000|0|0|4
22283|13593|postgres|16384|CLUSTER|performing final cleanup|16387|100000|100000|0|0|5
===================

Thanks,
Tatsuro Yamada

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-09-17 03:53:45 Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
Previous Message David Fetter 2019-09-17 03:18:26 Re: Fwd: Extending range type operators to cope with elements