On Tue, 4 Apr 2023 at 11:18, Andres Freund <and...@anarazel.de> wrote: > It sounds too hard compared to the gains, but another way could be to plan > with the relevant path generation hard disabled, and plan from scratch, with > additional scan types enabled, if we end up being unable to generate valid > plan.
I think there would be quite a bit of work to do before we could ever start to think about that. The planner does quite a bit of writing on the parse, e.g adding new RangeTblEntrys to the query's rtable. We'd either need to fix all those first or make a copy of the parse before planning. The latter is quite expensive today. It's also not clear to me how you'd know what you'd need to enable again to get the 2nd attempt to produce a plan this time around. I'd assume you'd want the minimum possible set of enable_* GUCs turned back on, but what would you do in cases where there's an aggregate and both enable_hashagg and enable_sort are both disabled and there are no indexes providing pre-sorted input? David David
