On Fri, Jun 1, 2018 at 9:47 AM, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>> On 1 June 2018 at 07:19, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>
>> Partition pruning is working now.
>>
>> Is it expected? Tested on fresh master.
>
> That's interesting. So there are two cases:
>
> * vlozeno > (select current_date) (pruning works)
>
> * vlozeno > current_date (pruning doesn't work)
>
> In pull_partkey_params when we need to extract Params matching partition key in
> the first case everything is fine, we've got an expr of type Param. In the
> second case we've got a SQLValueFunction, which is ignored in the code - so
> eventually we think that there is nothing matching a partition key and we don't
> need to apply pruning.
>
> With the attached hacky patch it would be taken into account (although I assume
> in reality SQLValueFunction should be treated somehow differently) and pruning
> is happening:
I think the patch is right if we were to handle only SQLValueFunction,
but the bigger picture here is that we aren't evaluating stable
functions before run-time partition pruning happens. I was under the
impression that the stable functions/expressions get evaluated and
folded into a constant just before the execution begins since a stable
function produces the same output for same input during one execution
invocation. But I am not able to find where we do that and probably we
don't do that at all. If we could do that then it's matter of using
same methods as plan-time partition pruning to prune the partitions.
If we go ahead with this patch, we should at least update it to handle
stable functions for the sake of completeness.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company