Re: Small run-time pruning doc fix - Mailing list pgsql-hackers

From David Rowley
Subject Re: Small run-time pruning doc fix
Date
Msg-id CAKJS1f8Wpec2+04rgdYrP0-5Z7EckjFm7qioHyXgAHqfNGLv7w@mail.gmail.com
Whole thread Raw
In response to Re: Small run-time pruning doc fix  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Small run-time pruning doc fix
List pgsql-hackers
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],
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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
Next
From: John Naylor
Date:
Subject: Re: WIP: Avoid creation of the free space map for small tables