Subject: Re: REINDEX not updating partition progress

From: Michael Paquier <[email-masked]>
Date: Thu, 25 Jul 2024 17:55:19 +0900

On Sun, Jul 21, 2024 at 11:41:43AM +0100, Ilya Gladyshev wrote:
> Forgot to update partition_relid in reindex_index in the second patch. Fixed in attachment.

        <structfield>relid</structfield> <type>oid</type>
       </para>
       <para>
-       OID of the table on which the index is being created.
+       OID of the table on which the command was run.
       </para></entry>

Hmm.  I am not sure if we really need to change the definition of this
field, because it can have the same meaning when using a REINDEX on a
partitioned table, pointing to the parent table (the partition) of the
index currently rebuilt.

Hence, rather than a partition_relid, could a partitioned_relid
reflect better the situation, set only when issuing a REINDEX on a
partitioned relation?

+   if (relkind == RELKIND_PARTITIONED_INDEX)
+   {
+       heapId = IndexGetRelation(relid, true);
+   }
Shouldn't we report the partitioned index OID rather than its parent
table when running a REINDEX on a partitioned index?
--
Michael

---

From: Ilya Gladyshev <[email-masked]>
Date: Thu, 25 Jul 2024 22:21:49 +0100

> 25 июля 2024 г., в 09:55, Michael Paquier <[email-masked]> 
> написал(а):
>

I'm not quite happy with the documentation update, but I think the 
approach for partitioned tables in this patch makes sense. I checked 
what other commands, that deal with partitions, (CREATE INDEX and 
ANALYZE) do, and they put a root partitioned table in "relid". ANALYZE 
has a separate column for the id of partition named 
current_child_table_relid, so I think it makes sense to have REINDEX do 
the same.

In addition, the current API for progress tracking doesn't have a way of 
updating "relid" without wiping out all other fields (that's what 
pgstat_progress_start_command does). This can definitely be changed, but 
that's another thing that made me not think in this direction.

> —

It’s used to update the "relid" field of the progress report. It’s the 
one that’s described in docs currently as "OID of the table on which the 
index is being created.", so I think it’s correct.