upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-04-01 15:26:56 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Doc: fix stale text about partition locking with cached plans

Browse source 
Commit 121d774cae added text to master describing pruning-aware
locking behavior introduced by 525392d57.  That behavior was
reverted in May 2025, making the text incorrect.  Replace it with
the text used in back branches, which correctly describes current
behavior: pruned partitions are still locked at the beginning of
execution.

Discussion: https://postgr.es/m/CA+HiwqFT0fPPoYBr0iUFWNB-Og7bEXB9hB=6ogk_qD9=OM8Vbw@mail.gmail.com
This commit is contained in:
Amit Langote 2026-03-30 10:29:21 +09:00
parent 1ad7191f7e
commit c57d8178eb
1 changed files with 3 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
doc/src/sgml/ddl.sgml
View file

@ -5416,13 +5416,9 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
It is possible to determine the number of partitions which were
removed during this phase by observing the
<quote>Subplans Removed</quote> property in the
<command>EXPLAIN</command> output. The query planner obtains locks for
all partitions which are part of the plan. However, when the executor
uses a cached plan, locks are only obtained on the partitions which
remain after partition pruning done during the initialization phase of
execution, i.e., the ones shown in the <command>EXPLAIN</command>
output and not the ones referred to by the
<quote>Subplans Removed</quote> property.
<command>EXPLAIN</command> output. It's important to note that any
partitions removed by the partition pruning done at this stage are
still locked at the beginning of execution.
</para>
</listitem>