> On Jul 21, 2025, at 00:03, Tom Lane wrote:
>
> feichanghong writes:
>> Currently, I have not found a better way to rewrite this, except by
>> optimizing
>> this scenario from the pg kernel side.
>
> If you're willing to modify your query, you could fake it out by
> spelling the subquery's
feichanghong writes:
> Currently, I have not found a better way to rewrite this, except by optimizing
> this scenario from the pg kernel side.
If you're willing to modify your query, you could fake it out by
spelling the subquery's "a = 1" condition in a way that won't produce an
EquivalenceClass
> On Jul 19, 2025, at 13:15, Zhang Mingli wrote:
>
> Hi,
>
> On Jul 18, 2025 at 22:52 +0800, feichanghong , wrote:
>
> explain select * from (select * from t where a = 1 and b > 1 order by a, b)
> order by a, b limit 1;
>QUERY PLAN
> --
Hi,
On Jul 18, 2025 at 22:52 +0800, feichanghong , wrote:
>
> explain select * from (select * from t where a = 1 and b > 1 order by a, b)
> order by a, b limit 1;
> QUERY PLAN
>
> On Jul 18, 2025, at 22:37, feichanghong wrote:
>
> Should we retain the complete `pathkeys` in `Path->pathkeys` for use by the
> upper layers of the subquery, rather than just keeping the portion trimmed by
> `PlannerInfo->query_pathkeys`? I'm not sure if my understanding is correct.
Currentl
Hi,
Recently, I found while using `union all order by limit` that `MergeAppend`
adds a `Sort` node even when child node data is already ordered, leading to
low execution efficiency.
The issue can be reproduced with the following case (on the latest master
branch). In the execution plan below, alt
