Re: BUG #19377: Query planner interesting behaviour

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

In response to

Responses

Browse pgsql-bugs by date

  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.