| 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?
>
| 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 |