Re: why partition pruning doesn't work?
От | Pavel Stehule |
---|---|
Тема | Re: why partition pruning doesn't work? |
Дата | |
Msg-id | CAFj8pRD=s-1U-unNa+gkTU0-tJ9ccBWvFVwx6=3-07R_Km=eUA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why partition pruning doesn't work? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2018-06-01 17:53 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> 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.
We don't; there was a patch floating around to make that happen, but
it hasn't been updated lately.
I agree though that it seems strange to special-case SQLValueFunction
rather than any-stable-expression. As long as the evaluation happens
at executor start (i.e. with the query's run-time snapshot) it should
be reasonable to simplify any stable expression.
It's worth questioning whether this is a bug fix or an improvement.
If the latter, it probably ought to wait for v12.
The result is correct - but it was unpleasant surprise. I searched the most simple demo for this feature, and it doesn't work. Filtering based on CURRENT_DATE is often.
Regards
Pavel
regards, tom lane
В списке pgsql-hackers по дате отправления: