From: | Tattsu Yama <yamatattsu(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, 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-15 03:35:10 |
Message-ID: | CAOKkKFtGo-DOPSO67vw6RfahM3A-hm-pqGm0+6URwp14JeLEKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2019-09-15 07:18:49 | Efficient output for integer types |
Previous Message | Tom Lane | 2019-09-14 23:01:33 | Re: Rethinking opclass member checks and dependency strength |