Re: [HACKERS] path toward faster partition pruning

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