From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: why partition pruning doesn't work? |
Date: | 2018-06-01 15:43:55 |
Message-ID: | CAFjFpResLp-PnVv7qBBagM-1ia6+h3pnCfDM+AJUAVWOTgHt8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 1, 2018 at 9:47 AM, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
>> On 1 June 2018 at 07:19, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rui DeSousa | 2018-06-01 15:44:47 | Re: Possible optimisation: push down SORT and LIMIT nodes |
Previous Message | Tom Lane | 2018-06-01 15:27:14 | Re: I'd like to discuss scaleout at PGCon |