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
