Re: MergeAppend could consider sorting cheapest child path - Mailing list pgsql-hackers

From Richard Guo
Subject Re: MergeAppend could consider sorting cheapest child path
Date
Msg-id CAMbWs48FxC5qsTif9F4E_FcmyAeNx9_N6RpV2YuGKPN0a5wnog@mail.gmail.com
Whole thread Raw
In response to Re: MergeAppend could consider sorting cheapest child path  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: MergeAppend could consider sorting cheapest child path
List pgsql-hackers
On Tue, Sep 2, 2025 at 5:26 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> I have another idea.  What if we allow MergeAppend paths only when at
> least one subpath is preordered.  This trick also allow us to exclude
> MergeAppend(Sort) dominating Sort(Append).  I see the regression tests
> changes now have much less volume and looks more reasonable.  What do
> you think?

I skimmed through the test case changes, and I'm not sure all of them
are actual improvements.  For example:

          ->  Append
-               ->  Foreign Scan on ftprt1_p1 t1_1
+               ->  Sort
+                     Sort Key: t1_1.a
+                     ->  Foreign Scan on ftprt1_p1 t1_1
                ->  Foreign Scan on ftprt1_p2 t1_2

It seems that this patch moves the sort operation for ftprt1_p1 from
the remote server to local.  I'm not sure if this is an improvement,
or why it applies only to ftprt1_p1 and not to ftprt1_p2 (they have
very similar statistics).

Besides, I noticed that some plans have changed from an "Index Scan
with Index Cond" to a "Seq Scan with Filter + Sort".  I'm also not
sure whether this change results in better performance.

- Richard



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Extension security improvement: Add support for extensions with an owned schema
Next
From: Chao Li
Date:
Subject: Re: SQL:2023 JSON simplified accessor support