On Mon, Apr 3, 2023 at 2:04 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Yeah. In some places it would not be too hard; for example, if we > generated seqscan paths last instead of first for baserels, the rule > could be "generate it if enable_seqscan is on OR if we made no other > path for the rel". It's much messier for joins though, partly because > the same joinrel will be considered multiple times as we process > different join orderings, plus it's usually unclear whether failing > to generate any paths for joinrel X will lead to overall failure.
Yeah, good point. I'm now remembering that at one point I'd had the idea of running the whole find-a-plan-for-a-jointree step and then running it a second time if it fails to find a plan. But I think that requires some restructuring, because I think right now it does some things that we should only do once we know we're definitely getting a plan out. Or else we have to reset some state. Like if we want to go back and maybe add more paths then we have to undo and redo whatever set_cheapest() did. > A solution that would work is to treat disable_cost as a form of infinity > that's counted separately from the actual cost estimate, that is we > label paths as "cost X, plus there are N uses of disabled plan types". > Then you sort first on N and after that on X. But this'd add a good > number of cycles to add_path, which I've not wanted to expend on a > non-mainstream usage. Yeah, I thought of that at one point too and rejected it for the same reason. -- Robert Haas EDB: http://www.enterprisedb.com
