On Mon Jul 13, 2026 at 8:55 PM -03, Tomas Vondra wrote: > Which last patch you mean? The v4 creates the scan paths with filters at > the beginning of the planning, which seems exactly the opposite to the > post-processing approach. Which means it can change the join order, it > can change which join algorithms we selected, etc. > > The approach in v1 is what I'd call post-processing, as it made the > decisions in createplan, after everything else was already decided. It > could not change join order or join algorithms, it was entirely > opportunistic. >
Sorry, that last paragraph was confusing — I didn't reread my reply before sending it. I mixed up the v1 and v4 implementations while writing it. What I actually meant to say is that v4 (and v5, as an evolution of v4, which I sent in my previous reply) seems like the way to go. Of course there's a lot to improve and think about, but the overall idea — creating paths with and without the pushed-down filters, accounting for them when costing the scan path, and letting the cost-based path selection decide which is better — makes sense to me. It consider the fact that pushing down filters is not free and it did not make EXPLAIN consufing with the expected x actual problem. > Some engines may do that unconditionally in the post-planning phase. It > can't change the plan anyway, so why bother with costing, right? But > then they still do some cost/benefit decisions at execution time, either > when deciding to build the filters, or to disable filters that turn out > to be ineffective. > > As for the expected vs actual difference, I think this would be a big > issue, because it'd make EXPLAIN output utterly confusing. I don't think > I could convince myself to commit that into core ... > I definitely agree with this, it can lead to a lot of confusion, e.g., "is the expected-vs-actual difference because of filter pushdown, or because the statistics are out of date?" So I'd also like to avoid that kind of behavior. -- Matheus Alcantara EDB: https://www.enterprisedb.com
