Message-ID: <82e59270-d4a0-4dbb-9c2d-5cd2005c933f@gmail.com>
Date: Wed, 21 Jan 2026 12:11:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19386: Unnecessary Sort in query plan for SELECT literal
 with ORDER BY
To: 798604270@qq.com, pgsql-bugs@lists.postgresql.org,
 PG Bug reporting form <noreply@postgresql.org>
References: <19386-be594598921461b9@postgresql.org>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <19386-be594598921461b9@postgresql.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/82e59270-d4a0-4dbb-9c2d-5cd2005c933f%40gmail.com>
Precedence: bulk

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