Re: [HACKERS] CLUSTER command progress monitor

Поиск
Список
Период
Сортировка
От Tattsu Yama
Тема Re: [HACKERS] CLUSTER command progress monitor
Дата
Msg-id CAOKkKFtGo-DOPSO67vw6RfahM3A-hm-pqGm0+6URwp14JeLEKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] CLUSTER command progress monitor  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: [HACKERS] CLUSTER command progress monitor  (Tattsu Yama <yamatattsu@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Rethinking opclass member checks and dependency strength
Следующее
От: David Fetter
Дата:
Сообщение: Efficient output for integer types