Re: [HACKERS] CLUSTER command progress monitor - Mailing list pgsql-hackers

From Tattsu Yama
Subject Re: [HACKERS] CLUSTER command progress monitor
Date
Msg-id CAOKkKFtGo-DOPSO67vw6RfahM3A-hm-pqGm0+6URwp14JeLEKw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] CLUSTER command progress monitor  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [HACKERS] CLUSTER command progress monitor
List pgsql-hackers
Hi Michael!

> Attached file is WIP patch.In my patch, I added "command id" to all APIs of
> progress reporting to isolate commands. Therefore, it doesn't allow to
> cascade updating system views. And my patch is on WIP so it needs clean-up
> and test.
> I share it anyway. :)

+       if (cmdtype == PROGRESS_COMMAND_INVALID || beentry->st_progress_command == cmdtype)
+       {
+               PGSTAT_BEGIN_WRITE_ACTIVITY(beentry);
+               beentry->st_progress_param[index] = val;
+               PGSTAT_END_WRITE_ACTIVITY(beentry);
+       }
You basically don't need the progress reports if the command ID is
invalid, no?


Ah, right.
I'll check and fix that today. :)

 

Another note is that you don't actually fix the problems related to
the calls of pgstat_progress_end_command() which have been added for
REINDEX reporting, so a progress report started for CLUSTER can get
ended earlier than expected, preventing the follow-up progress updates
to show up.



Hmm... I fixed the problem. Please confirm the test result repeated below. 
CLUSTER is able to get the last phase: performing final clean up by using the patch.

# Test result 
========================================
postgres=# select * from pg_stat_progress_cluster ; \watch 0.001;
11636|13591|postgres|16384|CLUSTER|initializing|0|0|0|0|0|0
11636|13591|postgres|16384|CLUSTER|index scanning heap|16389|251|251|0|0|0
11636|13591|postgres|16384|CLUSTER|index scanning heap|16389|10000|10000|0|0|0
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|0  <== The last column rebuild_index_count is increasing!
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|1
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|2
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|3
11636|13591|postgres|16384|CLUSTER|rebuilding index|16389|10000|10000|0|0|4
11636|13591|postgres|16384|CLUSTER|performing final cleanup|16389|10000|10000|0|0|5  <== The last phase of CLUSTER!
======================================== 

Thanks,
Tatsuro Yamada


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rethinking opclass member checks and dependency strength
Next
From: David Fetter
Date:
Subject: Efficient output for integer types