Thanks for the comment.
On 2018/04/09 23:22, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> I noticed that the newly added pruning does not work if the partition key
>> is of one of the types that have a corresponding pseudo-type.
>
> While I don't recall the details due to acute caffeine shortage,
> there are specific coding patterns that are used in the planner
> (e.g. in indxpath.c) to ensure that the code works with pseudotype
> opclasses as well as simple ones. The existence of this bug
> indicates that those conventions were not followed in the pruning
> code. I wonder whether this patch makes the pruning code look
> more like the pre-existing code, or even less like it.
Ah, I think I got it after staring at the (btree) index code for a bit.
What pruning code got wrong is that it's comparing the expression type
(type of the constant arg that will be compared with partition bound
datums when pruning) with the partopcintype to determine if we should look
up the cross-type comparison/hashing procedure, whereas what the latter
should be compare with is the clause operator's oprighttype. ISTM, if
op_in_opfamily() passed for the operator, that's the correct thing to do.
Once I changed the code to do it that way, no special considerations are
needed to handle pseudo-type type partition key.
Attached please find the updated patch.
Thanks,
Amit