On 21/1/26 09:26, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19386
> Logged by: Chi Zhang
> Email address: 798604270@qq.com
> PostgreSQL version: 18.1
> Operating system: ubuntu 24.04 with docker
> Description:
>
> Hi,
>
> In the following test case, there are two equivalent queries. One is a
> normal SELECT, and the other is a prepared SELECT. In the query plan of the
> normal SELECT, there is an unnecessary Sort, which causes it to be slower
> than the prepared SELECT. In general, the prepared SELECT should be slower
> than the normal SELECT, as its query plan is suboptimal. So there maybe
> potential opportunities for further optimization in the query planning of
> normal SELECT statements.
These queries aren't equivalent for me. The generic case may produce
errors if a parameter has an incompatible type. The 'simple query' case
validates constants and may simplify the clause, being sure no logical
errors happen during clause evaluation.
Another question - should we do anything to optimise this quite narrow
(at least it seems so for me) case and stop simplification of the clause?
--
regards, Andrei Lepikhov,
pgEdge
