Re: BUG #19386: Unnecessary Sort in query plan for SELECT literal with ORDER BY

From: Pierre Forstmann <pierre(dot)forstmann(at)gmail(dot)com>
To: 798604270(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, PG Bug reporting form <noreply(at)postgresql(dot)org>
Subject: Re: BUG #19386: Unnecessary Sort in query plan for SELECT literal with ORDER BY
Date: 2026-01-21 11:42:50
Message-ID: 1ffee916-e255-4a82-afd0-5f8a87c0ab87@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

It's only a detail but I don't understand why '*' is added to some table
name if there are no table inheritance ?

https://www.postgresql.org/docs/18/sql-select.html  says

/|table_name|/

The name (optionally schema-qualified) of an existing table or view.
If |ONLY| is specified before the table name, only that table is
scanned. If |ONLY| is not specified, the table and all its
descendant tables (if any) are scanned. Optionally, |*| can be
specified after the table name to explicitly indicate that
descendant tables are included.

Le 21/01/2026 à 12:11, Andrei Lepikhov a écrit :

> 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(at)qq(dot)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?
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrei Lepikhov 2026-01-21 11:57:13 Re: BUG #19385: Normal SELECT generates an ineffecifient query plan compare to the prepared SELECT.
Previous Message Dean Rasheed 2026-01-21 11:20:37 Re: BUG #19380: Transition table in AFTER INSERT trigger misses rows from MERGE when used with INSERT in a CTE