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 | Resend email |
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 |
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 |