Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id CAKJS1f9CfuGi1FLwj054taExXfd7sfXc+BwR0avPjYQv9hNWSA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] Runtime Partition Pruning
List pgsql-hackers
On 8 April 2018 at 00:23, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> I edited it as attached, to 1. avoid mentioning functionality that
> doesn't yet exist, and 2. avoid excessive internal detail (we want a
> high-level overview here), which from experience gets outdated pretty
> quickly.

It's not exactly wrong but:

+ * are turned into a set of "pruning steps", which are then executed to
+ * produce a set of RTIs of partitions whose bounds satisfy the constraints in
+ * the step.  Partitions not in the set are said to have been pruned.

It's only prune_append_rel_partitions which is only used for the
planner's pruning needs that converts the partition indexes to RTIs.
Would it be better to mention that the output is partition indexes?
Maybe:

"which are then executed to produce a set of partition indexes whose
bounds satisfy the constraints in the step. These partition indexes
may then be translated into RTIs", or maybe even not mention the RTIs.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Mop-up for the bootstrap data conversion patch
Next
From: Teodor Sigaev
Date:
Subject: Re: WIP: Covering + unique indexes.