David Rowley <[email protected]> writes:
> I don't think you'd need to wait longer than where we do set_cheapest
> and find no paths to find out that there's going to be a problem.
At a base relation, yes, but that doesn't work for joins: it may be
that a particular join cannot be formed, yet other join sequences
will work. We have that all the time from outer-join ordering
restrictions, never mind enable_xxxjoin flags. So I'm not sure
that we can usefully declare early failure for joins.
> I think the int Path.disabledness idea is worth coding up to try it.
> I imagine that a Path will incur the maximum of its subpath's
> disabledness's then add_path() just needs to prefer lower-valued
> disabledness Paths.
I would think sum not maximum, but that's a detail.
> That doesn't get you the benefits of fewer CPU cycles, but where did
> that come from as a motive to change this? There's no shortage of
> other ways to make the planner faster if that's an issue.
The concern was to not *add* CPU cycles in order to make this area
better. But I do tend to agree that we've exhausted all the other
options.
BTW, I looked through costsize.c just now to see exactly what we are
using disable_cost for, and it seemed like a majority of the cases are
just wrong. Where possible, we should implement a plan-type-disable
flag by not generating the associated Path in the first place, not by
applying disable_cost to it. But it looks like a lot of people have
erroneously copied the wrong logic. I would say that only these plan
types should use the disable_cost method:
seqscan
nestloop join
sort
as those are the only ones where we risk not being able to make a
plan at all for lack of other alternatives.
There is also some weirdness around needing to force use of tidscan
if we have WHERE CURRENT OF. But perhaps a different hack could be
used for that.
We also have this for hashjoin:
* If the bucket holding the inner MCV would exceed hash_mem, we don't
* want to hash unless there is really no other alternative, so apply
* disable_cost.
I'm content to leave that be, if we can't remove disable_cost
entirely.
What I'm wondering at this point is whether we need to trouble with
implementing the separate-disabledness-count method, if we trim back
the number of places using disable_cost to the absolute minimum.
regards, tom lane
