Re: path toward faster partition pruning

On Tue, Sep 26, 2017 at 2:45 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2017/09/25 20:21, Dilip Kumar wrote:

> I see. So, in the run-time pruning case, only the work of extracting
> bounding values is deferred to execution time. Matching clauses with the
> partition key still occurs during planning time. Only that the clauses
> that require run-time pruning are not those in rel->baserestrictinfo.

Right.
>
>> After separating out the matching clause we will do somewhat similar
>> processing what "get_rel_partitions" is doing. But, at optimizer time
>> for PARAM we will not have Datum values for rightop, so we will keep
>> track of the PARAM itself.
>
> I guess information about which PARAMs map to which partition keys will be
> kept in the plan somehow.

Yes.
>
>> And, finally at runtime when we get the PARAM value we can prepare
>> minkey and maxkey and call get_partitions_for_keys function.
>
> Note that get_partitions_for_keys() is not planner code, nor is it bound
> with any other planning code. It's callable from executor without much
> change. Maybe you already know that though.

Yes, Right.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com