Re: [HACKERS] path toward faster partition pruning

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] path toward faster partition pruning
Date: 2018-03-13 11:37:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2018/03/07 20:58, Amit Langote wrote:
> Hi.
> On 2018/03/05 17:38, Amit Langote wrote:
>> I'll
>> post an update in a couple of days to report on how that works out.
> I'm still working on this and getting most of the tests to pass with the
> new code, but not all of them yet.

Sorry about the delay.

Attached is a significantly revised version of the patch, although I admit
it could still use some work with regard to comments and other cleanup.

The rewrite introduces a notion of PartitionPruneStep nodes based on the
ideas described in [1]. So, instead of aggregating *all* of the pruning
clauses into a PartitionClauseInfo which was hard to serialize into a node
tree and then a PartScanKeyInfo (both of which no longer exist), this
generates a list of nodes. Each node inherits from the base
PartitionPruneStep node type and contains information enough to perform
partition pruning by directly comparing the information with partition
bounds or contains sub-nodes that do. For example, a PartitionPruneStepOp
step contains an integer telling the partitioning operator strategy (such
as various btree operator strategies) and a tuple to compare against
partition bounds stored in the relcache. A PartitionPruneStepCombine step
contains arguments that are in turn pruning steps themselves, which are
separately executed and partition sets obtained thereby are combined using
the specified combineOp.

Also, fixed a bug of the previous design as detailed in [2]. So, with the

create table lparted (a smallint) partition by list (a);
create table lparted_1 partition of lparted for values in (1);
create table lparted_16384 partition of lparted for values in (16384);

-- all partitions pruned (lparted_16384 wouldn't be pruned by previous
-- patches due to comparison using bogus a partsupfunc)

explain (costs off) select * from lparted where a = 100000000000000;
One-Time Filter: false
(2 rows)


create table rparted (a smallint) partition by range (a);
create table rparted_1 partition of rparted for values from (1) to (10);
create table rparted_16384 partition of rparted for values from (10) to
create table rparted_maxvalue partition of rparted for values from (16384)
to (maxvalue);

-- all partitions except rparted_maxvalue pruned
explain (costs off) select * from rparted where a > 100000000000000;
-> Seq Scan on rparted_maxvalue
Filter: (a > '100000000000000'::bigint)
(3 rows)

I will continue working on improving the comments / cleaning things up and
post a revised version soon, but until then please look at the attached.




Attachment Content-Type Size
v36-0001-Add-partsupfunc-to-PartitionSchemeData.patch text/plain 3.4 KB
v36-0002-Add-more-tests-for-partition-pruning.patch text/plain 25.6 KB
v36-0003-Faster-partition-pruning.patch text/plain 91.3 KB
v36-0004-Add-only-unpruned-partitioned-child-rels-to-part.patch text/plain 23.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2018-03-13 12:02:14 Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Previous Message Simon Riggs 2018-03-13 11:04:03 Re: SQL/JSON: functions