Re: On disable_cost - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: On disable_cost |
Date | |
Msg-id | CA+Tgmob1bU2g109K4rpuYKcaWtmee_CzENat_myRR3T3PdQ5Cw@mail.gmail.com Whole thread Raw |
In response to | Re: On disable_cost (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: On disable_cost
(Greg Sabino Mullane <htamfids@gmail.com>)
|
List | pgsql-hackers |
On Mon, Apr 1, 2024 at 5:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Very interesting, thanks for the summary. So the fact that > disable_cost is additive across plan nodes is actually a pretty > important property of the current setup. I think this is closely > related to one argument you made against my upthread idea of using > IEEE Infinity for disable_cost: that'd mask whether more than one > of the sub-plans had been disabled. Yes, exactly. I just hadn't quite put the pieces together. > Yeah, that seems like the next thing to try if anyone plans to pursue > this further. That'd essentially do what we're doing now except that > disable_cost is its own "order of infinity", entirely separate from > normal costs. Right. I think that's actually what I had in mind in the last paragraph of http://postgr.es/m/CA+TgmoY+Ltw7B=1FSFSN4yHcu2roWrz-ijBovj-99LZU=9h1dA@mail.gmail.com but that was a while ago and I'd lost track of why it actually mattered. But I also have questions about whether that's really the right approach. I think the approach of just not generating paths we don't want in the first place merits more consideration. We do that in some cases already, but not in others, and I'm not clear why. Like, if index-scans, index-only scans, sorts, nested loops, and hash joins are disabled, something is going to have to give, because the only remaining join type is a merge join yet we've ruled out every possible way of getting the day into some order, but I'm not sure whether there's some reason that we need exactly the behavior that we have right now rather than anything else. Maybe it would be OK to just insist on at least one unparameterized, non-partial path at the baserel level, and then if that ends up forcing us to ignore the join-type restrictions higher up, so be it. Or maybe that's not OK and after I try that out I'll end up writing another email about how I was a bit clueless about all of this. I don't know. But I feel like it merits more investigation, because I'm having trouble shaking the theory that what we've got right now is pretty arbitrary. And also ... looking at the regression tests, and also thinking about the kinds of problems that I think people run into in real deployments, I can't help feeling like we've somehow got this whole thing backwards. enable_wunk imagines that you want to plan as normal except with one particular plan type excluded from consideration. And maybe that makes sense if the point of the enable_wunk GUC is that the planner feature might be buggy and you might therefore want to turn it off to protect yourself, or if the planner feature might be expensive and you might want to turn it off to save cycles. But surely that's not the case with something like enable_seqscan or enable_indexscan. What I think we're mostly doing in the regression tests is shutting off every relevant type of plan except one. I theorize that what we actually want to do is tell the planner what we do want to happen, rather than what we don't want to happen, but we've got this weird set of GUCs that do the opposite of that and we're super-attached to them because they've existed forever. I don't really have a concrete proposal here, but I wonder if what we're actually talking about here is spending time and energy polishing a mechanism that nobody likes in the first place. -- Robert Haas EDB: http://www.enterprisedb.com
pgsql-hackers by date: