Re: [HACKERS] path toward faster partition pruning

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: jesper(dot)pedersen(at)redhat(dot)com, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, 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-29 08:35:13
Message-ID: 48cd4ebe-4292-922a-1ee1-9bf47503625f@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 2018/03/29 1:41, Jesper Pedersen wrote:
> Just some trivial changes.

Thanks Jesper. Merged.

> However,
>
> explain (costs off) select * from mc2p where a = 2 and b < 1;
>
> is picking up
>
>    ->  Seq Scan on mc2p2
>          Filter: ((b < 1) AND (a = 2))
>
> which doesn't seem right, as its definition is
>
> create table mc2p2 partition of mc2p for values from (1, 1) to (2, minvalue);

Yeah, that wasn't right. It boiled down to how some code in the range
partition pruning function considered a tuple containing a = 2 to fall in
this partition, which is wrong because the minvalue in its upper bound
makes the partition exclusive of any tuples with a = 2. Fixed that.

Beside fixing that, I have decided to get rid of the
PartititionPruneStepOpNe (a special kind of base pruning step that was
being used to prune list partitions using a set of <> operator clauses)
and related functions. Instead pruning for <> operator clauses is now
implemented by using a combination of PartitionPruneStepOp and
PartitionPruneStepCombine after adding a new combine op COMBINE_INVERT (I
also renamed COMBINE_OR and COMBINE_AND to COMBINE_UNION and
COMBINE_INTERSECT, respectively). I decided to do so because the previous
arrangement looked like a "hack" to support a special case that touched no
less than quite a few places.

Attached find the updated version of patches.

Thanks,
Amit

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2018-03-29 08:37:31 Re: Commit fest 2017-11
Previous Message Magnus Hagander 2018-03-29 08:19:30 Re: Commit fest 2017-11