Ilya Gladyshev писал(а) 2024-05-28 02:52:
>> Also I'd like to note that in new patch version there's a strange
>> wording in documentation:
>>
>> "This can be very convenient as not only will all existing partitions
>> be
>> indexed, but any future partitions will be as well.
>> <command>CREATE INDEX ... CONCURRENTLY</command> can incur long lock
>> times
>> on huge partitioned tables, to avoid that you can
>> use <command>CREATE INDEX ON ONLY</command> the partitioned table,
>> which
>> creates the new index marked as invalid, preventing automatic
>> application
>> to existing partitions."
>>
>> All the point of CIC is to avoid long lock times. So it seems this
>> paragraph should be rewritten in the following way:
>>
>> "To avoid long lock times, you can use CREATE INDEX CONCURRENTLY or
>> CREATE INDEX ON ONLY</command> the partitioned table..."
>
>
> True, the current wording doesn't look right. Right now CREATE INDEX ON
> ONLY is described as a workaround for the missing CIC. I think it
> rather makes sense to say that it gives more fine-grained control of
> partition locking than both CIC and ordinary CREATE INDEX. See the
> updated patch.
Hi.
Not sure if it's worth removing mentioning of CIC in
creates the new index marked as invalid, preventing automatic
application
to existing partitions. Instead, indexes can then be created
individually
- on each partition using <literal>CONCURRENTLY</literal> and
+ on each partition and
<firstterm>attached</firstterm> to the partitioned index on the
parent
using <command>ALTER INDEX ... ATTACH PARTITION</command>. Once
indexes for
all the partitions are attached to the parent index, the parent
index will
but at least now it looks better.
--
Best regards,
Alexander Pyhalov,
Postgres Professional