Re: [HACKERS] CLUSTER command progress monitor

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

In response to

Responses

Browse pgsql-hackers by date

  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