On Fri, Jun 1, 2018 at 9:47 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> On 1 June 2018 at 07:19, Pavel Stehule <pavel.steh...@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