| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | postgresql(at)juneidy(dot)wibowo(dot)au, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19377: Query planner interesting behaviour |
| Date: | 2026-01-21 08:06:51 |
| Message-ID: | CAApHDvpbmPJbJsaKEicYD345cy4jXtW7Egrc+WLnhj8Mnwrddg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, 13 Jan 2026 at 21:57, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> It's weird that in the first query postgres doesn't seem to treat
> st_makevalid($0) as a constant and I think re-evaluate st_makevalue($0) for
> every row. Is that an expected behaviour?
Yes, it's expected. We don't do anything special to try and walk up
function call chains of immutable functions for init plan parameters
to push function calls down to the init plan. Perhaps something is
possible here, but anyone proposing we change this would need to come
armed with proof that it's safe to do this. It's not really clear to
me that doing this couldn't change some evaluation order and cause
changes which could result in errors being raised when they shouldn't
or not being raised when they should. We do only run the initplan if
the outer query has at least 1 row, so maybe it's safe, but it would
take some analysis to veryify that's true for all possible cases.
You're best to just put the SELECT in the position so as to minimise
the redundant function calls.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-01-21 08:26:39 | BUG #19386: Unnecessary Sort in query plan for SELECT literal with ORDER BY |
| Previous Message | PG Bug reporting form | 2026-01-21 06:53:11 | BUG #19385: Normal SELECT generates an ineffecifient query plan compare to the prepared SELECT. |