Re: MergeAppend could consider sorting cheapest child path

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