Re: Progress report of CREATE INDEX for nested partitioned tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Progress report of CREATE INDEX for nested partitioned tables
Дата
Msg-id 1634535.1678666528@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Progress report of CREATE INDEX for nested partitioned tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Progress report of CREATE INDEX for nested partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Progress report of CREATE INDEX for nested partitioned tables
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label