> That's a problem. I really think that we should make the steps of the
> concurrent operation consistent across all relations, meaning that all
> the indexes should be created as invalid for all the parts of the
> partition tree, including partitioned tables as well as their
> partitions, in the same transaction. Then a second new transaction
> gets used for the index build, followed by a third one for the
> validation that switches the indexes to become valid.
This is a good idea.
We should maintain the consistency of the entire partition table.
However, this is not a small change in the code.
May be we need to make a new design for DefineIndex function....
But most importantly, if we use three steps to implement CIC,
we will spend more time than ordinary tables, especially in high concurrency cases.
To wait for one of partitions which the users to use frequently,
the creation of other partition indexes is delayed.
Is it worth doing this?
Regards, Adger
------------------------------------------------------------------
发件人：Michael Paquier <michael@paquier.xyz>
发送时间：2020年6月15日(星期一) 20:37
收件人：李杰(慎追) <adger.lj@alibaba-inc.com>
抄 送：Justin Pryzby <pryzby@telsasoft.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>; 曾文旌(义从) <wenjing.zwj@alibaba-inc.com>; Alvaro Herrera <alvherre@2ndquadrant.com>
主 题：Re: 回复：how to create index concurrently on partitioned table
On Mon, Jun 15, 2020 at 08:15:05PM +0800, 李杰(慎追) wrote:
> As shown above, an error occurred while creating an index in the second partition.
> It can be clearly seen that the index of the partitioned table is invalid
> and the index of the first partition is normal, the second partition is invalid,
> and the Third Partition index does not exist at all.
That's a problem. I really think that we should make the steps of the
concurrent operation consistent across all relations, meaning that all
the indexes should be created as invalid for all the parts of the
partition tree, including partitioned tables as well as their
partitions, in the same transaction. Then a second new transaction
gets used for the index build, followed by a third one for the
validation that switches the indexes to become valid.
--
Michael