Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 17 January 2018 at 23:48, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> I'm concerned that after your patch to remove
> match_clauses_to_partkey(), we'd be doing more work than necessary in
> some cases. For example, consider the case of using run-time pruning
> for nested loop where the inner relation is a partitioned table. With
> the old approach, get_partitions_from_clauses() would only be handed
> the clauses that are known to match the partition keys (which most
> likely is fewer than all of the query's clauses), so
> get_partitions_from_clauses() doesn't have to do the work of filtering
> non-partition clauses every time (that is, for every outer row).
> That's why I had decided to keep that part in the planner.

That might be better served by splitting
classify_partition_bounding_keys() into separate functions, the first
function would be in charge of building keyclauses_all. That way the
remaining work during the executor would never need to match clauses
to a partition key as they'd be in lists dedicated to each key.

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