Small run-time pruning doc fix
Before 5220bb7533f a note in ddl.sgml used to mention that run-time
pruning was only implemented for Append. When we got MergeAppend
support the commit updated this to mention MergeAppend is supported
too. This is slightly weird as it's not all that obvious what exactly
isn't supported when we mention:
<para>
Both of these behaviors are likely to be changed in a future release
of <productname>PostgreSQL</productname>.
</para>
The attached patch updates this to mention that ModifyTable is
unsupported which I think makes the above fragment make sense again.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
small_runtime_pruning_doc_fix.patchapplication/octet-stream; name=small_runtime_pruning_doc_fix.patchDownload
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index b5ed1b7939..cab6cf24ee 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -3944,8 +3944,10 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
</para>
<para>
- Execution-time partition pruning currently occurs for the
+ Execution-time partition pruning currently only occurs for the
<literal>Append</literal> and <literal>MergeAppend</literal> node types.
+ It is not yet implemented for the <literal>ModifyTable</literal> node
+ type.
</para>
<para>
On 08/10/2018 10:22, David Rowley wrote:
Before 5220bb7533f a note in ddl.sgml used to mention that run-time
pruning was only implemented for Append. When we got MergeAppend
support the commit updated this to mention MergeAppend is supported
too. This is slightly weird as it's not all that obvious what exactly
isn't supported when we mention:<para>
Both of these behaviors are likely to be changed in a future release
of <productname>PostgreSQL</productname>.
</para>The attached patch updates this to mention that ModifyTable is
unsupported which I think makes the above fragment make sense again.
<para>
- Execution-time partition pruning currently occurs for the
+ Execution-time partition pruning currently only occurs for the
<literal>Append</literal> and <literal>MergeAppend</literal> node
types.
+ It is not yet implemented for the <literal>ModifyTable</literal> node
+ type.
</para>Isn't this implied by the preceding paragraph
Currently, pruning of partitions during the planning of an UPDATE or
DELETE command is implemented using the constraint exclusion method
?
Also, could there be other node types that could benefit from partition
pruning that are not implemented yet? Not sure we want to mention all
of them.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Thanks for looking at this.
On 2 November 2018 at 20:30, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
<para> - Execution-time partition pruning currently occurs for the + Execution-time partition pruning currently only occurs for the <literal>Append</literal> and <literal>MergeAppend</literal> node types. + It is not yet implemented for the <literal>ModifyTable</literal> node + type. </para>Isn't this implied by the preceding paragraph
Currently, pruning of partitions during the planning of an UPDATE or
DELETE command is implemented using the constraint exclusion method
That paragraph is talking about plan-time partition pruning. The
paragraph the patch changes is mentioning execution-time partition
pruning. In PG11 we have plan-time partition pruning for Append and
MergeAppend. UPDATE/DELETE does pruning, but it uses the constraint
exclusion code which does not work for HASH partitioned tables. In
PG11 we only have run-time partition pruning for Append. MergeAppend
support was only added in 5220bb7533 (PG12).
Also, could there be other node types that could benefit from partition
pruning that are not implemented yet? Not sure we want to mention all
of them.
I'm unsure what might exist in the future, but there are currently
only 3 node types that take a list of subpaths. I think if we get the
support for ModifyTable later, then likely the paragraph edited in
this patch would disappear. In fact, the entire note would disappear
as adding run-time pruning for ModifyTable will require the planner to
use the new partition pruning code. There's a patch for that in [1]https://commitfest.postgresql.org/20/1778/,
so maybe it'll all be a little less confusing in PG12.
[1]: https://commitfest.postgresql.org/20/1778/
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 04/11/2018 06:23, David Rowley wrote:
Thanks for looking at this.
On 2 November 2018 at 20:30, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:<para> - Execution-time partition pruning currently occurs for the + Execution-time partition pruning currently only occurs for the <literal>Append</literal> and <literal>MergeAppend</literal> node types. + It is not yet implemented for the <literal>ModifyTable</literal> node + type. </para>Isn't this implied by the preceding paragraph
Currently, pruning of partitions during the planning of an UPDATE or
DELETE command is implemented using the constraint exclusion methodThat paragraph is talking about plan-time partition pruning. The
paragraph the patch changes is mentioning execution-time partition
pruning. In PG11 we have plan-time partition pruning for Append and
MergeAppend. UPDATE/DELETE does pruning, but it uses the constraint
exclusion code which does not work for HASH partitioned tables. In
PG11 we only have run-time partition pruning for Append. MergeAppend
support was only added in 5220bb7533 (PG12).
I see now. The actual documentation change was separate in db72302b0a8.
Committed your change.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 13 November 2018 at 02:46, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
Committed your change.
Thanks.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services