回复：回复：回复：how to create index concurrently on partitioned table

> We can refer to the implementation in the ReindexRelationConcurrently,
> in the three phases of the REINDEX CONCURRENTLY,
> all indexes of the partitions are operated one by one in each phase.
> In this way, we can maintain the consistency of the entire partitioned table index.
> After we implement CIC in this way, we can also complete reindex partitioned table index concurrently (this is not done now.)

After careful analysis, I found that there were two choices that embarrassed me.
Although we can handle the entire partition tree with one transaction in each of the three phases of CIC, just like ordinary tables.

However, I found a problem. If there are many partitions,
we may need to handle too many missing index entries when validate_index() .
Especially for the first partition, the time may have been long and many entries are missing.
In this case, why don't we put the second and third phase together into a transaction for each partition?

So, which schema do you think is better?
Choose to maintain consistency in all three phases,
or just maintain consistency in the first phase?

Thank you very much,
Regards, Adger