On Sun, Mar 12, 2023 at 04:14:06PM -0400, Tom Lane wrote: > Justin Pryzby <pry...@telsasoft.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