| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
| Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, 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:53:39 |
| Message-ID: | 7142.1527868419@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2018-06-01 15:56:39 | Re: I'd like to discuss scaleout at PGCon |
| Previous Message | Rui DeSousa | 2018-06-01 15:44:47 | Re: Possible optimisation: push down SORT and LIMIT nodes |