On Wed, Aug 26, 2026 at 11:03 PM Tom Lane <[email protected]> wrote: > I'm skeptical that this example is a deal-breaker, because it seems > quite artificial. Queries with this many relations would typically > take a long time to plan. If we're somewhat slower to deal with the > edge case where most of the joins vanish, is anyone really likely to > notice? So I'm hesitant to add complexity in hopes of making the > edge case faster. Especially since this is a bug fix that I'm hoping > to back-patch; every dollop of complexity adds risk.
Fair enough. Thinking about it more, this regression only happens when we remove a lot of joins that depend on each other. In that case, the query becomes smaller after each restart, so the total planning time is still much less than planning the query with all those joins. Also, I do not like my proposal about recomputing attr_needed very much. It computes attr_needed again in another place, which would be a maintenance burden, especially in stable branches. So let's not do it. - Richard
