Re: MergeAppend could consider sorting cheapest child path

On Tue, Sep 2, 2025 at 5:26 AM Alexander Korotkov <aekorotkov(at)gmail(dot)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