On Mon, Jun 21, 2021 at 9:52 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > I'm not so sure that it is. The point isn't the risk, even if it could > > be calculated. The point is the downsides of being wrong are huge and > > pretty much unbounded, whereas the benefits of being right are tiny > > and bounded. It almost doesn't matter what the underlying > > probabilities are. > > You're throwing around a lot of pejorative adjectives there without > having bothered to quantify any of them. This sounds less like a sound > argument to me than like a witch trial.
I'm not sure what you mean by pejorative. Isn't what I said about downsides and upsides pretty accurate? > Reflecting for a bit on the ancient principle that "the only good numbers > in computer science are 0, 1, and N", it seems to me that we could make > an effort to classify RelOptInfos as provably empty, provably at most one > row, and others. (This would be a property of relations, not individual > paths, so it needn't bloat struct Path.) We already understand about > provably-empty rels, so this is just generalizing that idea a little. It sounds like you're concerned about properly distinguishing between: 1. Cases where the only non-reckless choice is a hash join over a unparameterized nested loop join 2. Cases that look like that at first, that don't really have that quality on closer examination. This seems like a reasonable concern. > Once we know about that, at least for the really-common cases like unique > keys, I'd be okay with a hard rule that we don't consider unparameterized > nestloop joins with an outer side that falls in the "N" category. > Unless there's no alternative, of course. I thought that you were arguing against the premise itself. It's now clear that you weren't, though. I don't have an opinion for or against bringing the provably-empty rels stuff into the picture. At least not right now. -- Peter Geoghegan
