Re: BUG #19377: Query planner interesting behaviour - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #19377: Query planner interesting behaviour
Date
Msg-id CAApHDvpbmPJbJsaKEicYD345cy4jXtW7Egrc+WLnhj8Mnwrddg@mail.gmail.com
Whole thread Raw
In response to BUG #19377: Query planner interesting behaviour  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #19377: Query planner interesting behaviour
List pgsql-bugs
On Tue, 13 Jan 2026 at 21:57, PG Bug reporting form
<noreply@postgresql.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



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #19385: Normal SELECT generates an ineffecifient query plan compare to the prepared SELECT.
Next
From: PG Bug reporting form
Date:
Subject: BUG #19386: Unnecessary Sort in query plan for SELECT literal with ORDER BY