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 2003807.1679603746@sss.pgh.pa.us
Whole thread Raw
In response to Re: Progress report of CREATE INDEX for nested partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Progress report of CREATE INDEX for nested partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
So I'm still pretty desperately unhappy with count_leaf_partitions.
I don't like expending significant cost purely for progress tracking
purposes, I don't like the undocumented assumption that NoLock is
safe, and what's more, if it is safe then we've already traversed
the inheritance tree to lock everything so in principle we could
have the count already.  However, it does seem like getting that
knowledge from point A to point B would be a mess in most places.

One thing we could do to reduce the cost (and improve the safety)
is to forget the idea of checking the relkinds and just set the
PARTITIONS_TOTAL count to list_length() of the find_all_inheritors
result.  We've already agreed that it's okay if the PARTITIONS_DONE
count never reaches PARTITIONS_TOTAL, so this would just be taking
that idea further.  (Or we could increment PARTITIONS_DONE for
non-leaf partitions when we visit them, thus making that TOTAL
more nearly correct.)  Furthermore, as things stand it's not hard
for PARTITIONS_TOTAL to be zero --- there's at least one such case
in the regression tests --- and that seems just weird to me.

By the by, this is awful code:

+        if (RELKIND_HAS_STORAGE(get_rel_relkind(partrelid)))

Consult the definition of RELKIND_HAS_STORAGE to see why.
But I want to get rid of that rather than fixing it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Add standard collation UNICODE
Next
From: Andres Freund
Date:
Subject: Re: HOT chain validation in verify_heapam()