Re: Progress report of CREATE INDEX for nested partitioned tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Progress report of CREATE INDEX for nested partitioned tables
Date
Msg-id 1634535.1678666528@sss.pgh.pa.us
Whole thread Raw
In response to Re: Progress report of CREATE INDEX for nested partitioned tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Progress report of CREATE INDEX for nested partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
I wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
>> count_leaf_partitions() is also called for sub-partitions, in the case
>> that a matching "partitioned index" already exists, and the progress
>> report needs to be incremented by the number of leaves for which indexes
>> were ATTACHED.

> Can't you increment progress by one at the point where the actual attach
> happens?

Oh, never mind; now I realize that the point is that you didn't ever
iterate over those leaf indexes.

However, consider a thought experiment: assume for whatever reason that
all the actual index builds happen first, then all the cases where you
succeed in attaching a sub-partitioned index happen at the end of the
command.  In that case, the percentage-done indicator would go from
some-number to 100% more or less instantly.

What if we simply do nothing at sub-partitioned indexes?  Or if that's
slightly too radical, just increase the PARTITIONS_DONE counter by 1?
That would look indistinguishable from the case where all the attaches
happen at the end.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Progress report of CREATE INDEX for nested partitioned tables
Next
From: Michael Paquier
Date:
Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label