Re: Progress report of CREATE INDEX for nested partitioned tables

On Sun, Mar 12, 2023 at 04:14:06PM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> > On Fri, Mar 10, 2023 at 03:36:10PM -0500, Tom Lane wrote:
> >> I took a look through this. It seems like basically a good solution,
> >> but the count_leaf_partitions() function is bothering me, for two
> >> reasons:
>
> > ... find_all_inheritors() will also have been called by
> > ProcessUtilitySlow(). Maybe it's sufficient to mention that ?
>
> Hm. Could we get rid of count_leaf_partitions by doing the work in
> ProcessUtilitySlow? Or at least passing that OID list forward instead
> of recomputing it?

count_leaf_partitions() is called in two places:

Once to get PROGRESS_CREATEIDX_PARTITIONS_TOTAL. It'd be easy enough to
pass an integer total via IndexStmt (but I think we wanted to avoid
adding anything there, since it's not a part of the statement).

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. We'd need a mapping from OID => npartitions (or to
compile some data structure of all the partitioned partitions). I guess
CreateIndex() could call CreatePartitionDirectory(). But it looks like
that would be *more* expensive.

--
Justin