Re: postgres_fdw: Fix costing of remote sorts without remote estimates - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: postgres_fdw: Fix costing of remote sorts without remote estimates
Date
Msg-id DLWCNK7EPYMZ.2UMXT8Q36OCWL@jeltef.nl
Whole thread
In response to Re: postgres_fdw: Fix costing of remote sorts without remote estimates  (Rui Zhao <zhaorui126@gmail.com>)
Responses Re: postgres_fdw: Fix costing of remote sorts without remote estimates
List pgsql-hackers
On Fri Oct 2, 2026 at 6:29 PM CEST, Rui Zhao wrote:
> 1. I found a regression with a local filter and LIMIT:
> 2. Local projection costs can also prevent LIMIT pushdown. Using
>    sort_ft above:

Thanks for the review and finding these plan-regressions. It turns out
that the underlying problem isn't specific to my patch. With slightly
different queries master picks the same kind of bad plans. I did not use
your suggested fixes. Instead I changed estimate_path_cost_size() to
build up the costs in the order the work happens: remote work, then
transfer, then local work. That approach results in less code, and
that code is also easier to understand (imo). See the newly attached
patchset for details. It contains three preparatory patches before my
original patch:

1. Starts using run_cost instead of total_cost to make the fix easier to
   understand and also fixes a small bug
2. Adds tests to show the bad plans on master
3. Fixes the bad plans in the tests introduced by 2
4. My original patch (I only improved the comments a bit)

Attachment

pgsql-hackers by date:

Previous
From: Manu
Date:
Subject: Re: BUG #19686: Rolling back SET TABLESPACE
Next
From: Manu
Date:
Subject: Re: Planning time quadratic in the IN-list length for "c = X AND (a, b) IN (...)" with BitmapOr