On 2019-11-01 12:56:30 -0400, Robert Haas wrote: > On Fri, Nov 1, 2019 at 12:43 PM Andres Freund <and...@anarazel.de> wrote: > > As a first step I'd be inclined to "just" adjust disable_cost up to > > something like 1.0e12. Unfortunately much higher and and we're getting > > into the area where the loss of precision starts to be significant > > enough that I'm not sure that we're always careful enough to perform > > math in the right order (e.g. 1.0e16 + 1 being 1.0e16, and 1e+20 + 1000 > > being 1e+20). I've seen queries with costs above 1e10 where that costing > > wasn't insane. > > We've done that before and we can do it again. But we're going to need > to have something better eventually, I think, not just keep kicking > the can down the road.
Yea, that's why I continued on to describe what we should do afterwards ;) > Yet another approach would be to divide the cost into two parts, a > "cost" component and a "violations" component. If two paths are > compared, the one with fewer violations always wins; if it's a tie, > they compare on cost. A path's violation count is the total of its > children, plus one for itself if it does something that's disabled. > This would be more principled than the current approach, but maybe > it's too costly. Namely go for something like this. I think we probably get away with the additional comparison, especially if we were to store the violations as an integer and did it like if (unlikely(path1->nviolations != path2->nviolations)) or such - that ought to be very well predicted in nearly all cases. I wonder how much we'd need to reformulate compare_path_costs/compare_path_costs_fuzzily to allow the compiler to auto-vectorize. Might not be worth caring... Greetings, Andres Freund