David Rowley <david.row...@2ndquadrant.com> writes: > On 22 May 2017 at 16:10, David Rowley <david.row...@2ndquadrant.com> wrote: >> I also just noticed that I don't think I've got ANTI join cases >> correct in the patch I sent. I'll look at that now.
> I've attached an updated patch. > This one is much less invasive than my original attempt. Sorry for not dealing with this sooner --- I put it on the back burner for PGCon, and just now got back to it. First off, I agree that it was probably a mistake for this code to special-case LEFT/FULL joins at all. eqjoinsel() does not do so; it relies on the join-type correction applied later by calc_joinrel_size_estimate(). Since that correction is also downstream of this code, we should be able to do the same here, and indeed may be double-counting somehow if we don't. What that leaves is that we're using the "smallest per-column selectivity" hack only for SEMI/ANTI joins where we can't really get anything helpful from knowledge of the FK. What your patch does is to fall back on the traditional clauselist_selectivity calculation for the relevant clauses. But we'd be better off ignoring the FK altogether and leaving those clauses to be processed later. That saves some cycles, and it might allow those clauses to be used more fruitfully with a different FK, and even if that doesn't happen it's better to let clauselist_selectivity see as many clauses at once as possible. So I whacked the patch around to do it like that and pushed it. I'm not totally satisfied that there isn't any case where the smallest selectivity hack is appropriate. In the example you're showing here, the FK columns are independent so that we get more or less the right answer with or without the FK. But in some quick testing I could not produce a counterexample proving that that heuristic is helpful; so for now let's can it. Thanks, and sorry again for the delay. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers