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

From Justin Pryzby
Subject Re: Progress report of CREATE INDEX for nested partitioned tables
Date
Msg-id ZA5My7SUI0/VnmCS@telsasoft.com
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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Mar 12, 2023 at 04:14:06PM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby@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



pgsql-hackers by date:

Previous
From: Attila Soki
Date:
Subject: Re: WIP Patch: pg_dump structured
Next
From: Tom Lane
Date:
Subject: Re: Progress report of CREATE INDEX for nested partitioned tables