On Sat, Oct 5, 2024 at 3:35 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > BTW, getting off the question of EXPLAIN output for a moment, > I don't understand why disable_cost is still a thing. The > one remaining usage seems trivial to replace, as attached.
I believe I commented on that somewhere upthread, but maybe I meant to and didn't or maybe you didn't see it in the flurry of emails. Basically, I wasn't confident that it made sense to treat this as the same kind of thing as other cases where we increment disabled_nodes. Because I couldn't make up my mind what to do and didn't get clear feedback from anybody else, I did nothing. The thing is, if somebody says enable_mergejoin=false, presumably they REALLY, REALLY don't want a merge join. If we start using that same mechanism for other purposes -- like making sure that a hash join doesn't overrun work_mem -- then the user might get a merge join anyway because we've represented a hash join that is big, but not disabled, in the same way that we represent as merge join that is actually disabled. I'm pretty uncomfortable with that. Sure, the user probably doesn't want us to overrun work_mem either, but when push comes to shove, shouldn't a very explicit user instruction like "don't use a merge join, l don't want that!" take precedence over any sort of planner estimate? Estimates can be wrong, and the user is in charge. -- Robert Haas EDB: http://www.enterprisedb.com
