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
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 |