Hi Richard
> > > hashjointuples is the third count for all of the semi/anti join types. > > That's exactly right for otherquals and cpu_tuple_cost, but wrong for > > joinquals. For plain joins it is the second count, so there the > > charge is right for joinquals and pessimistic for otherquals. That is > > also what the comment below means: > I found an older explanation from Tom Lane that seems relevant here: > https://postgr.es/m/[email protected] > > He points out that costing joinrestrictinfo “returns the costs for ALL > the quals”, and that after subtracting hash_qual_cost, qp_qual_cost represents > all additional clauses beside the hash clauses. > > So in this case qp_qual_cost combines two executor qual classes with > different evaluation populations: non-hash joinquals and pushed-down > otherquals. It therefore seems that changing the multiplier for the combined > qp_qual_cost cannot in general make both parts correct. > > Would it make sense to split those two costs before applying the > right-anti candidate-pair multiplier? > > > Thanks
