On Wed, Feb 21, 2024 at 6:25 AM Richard Guo <guofengli...@gmail.com> wrote: > This patch was returned due to 'lack of interest'. However, upon > verification, it appears that the reported issue still exists, and the > proposed fix in the thread remains valid. Hence, resurrect this patch > after rebasing it on master. I've also written a detailed commit > message which hopefully can help people review the changes more > effectively.
I think it's slightly questionable whether this patch is worthwhile. The case memorialized in the regression tests, t1.a = t2.a AND t1.a = t2.b, is a very weird thing to do. The case mentioned in the original email, foo.k1 = bar.k1 and foo.k2 = bar.k2 and foo.k2 = 16, seems like something that could realistically happen, especially when there are views in use (e.g. the view joins foo and bar, and then someone queries the view for one of the join columns). In such a case, it's possible that foo.k2 = 16 is selective enough that we really don't care about partition-wise join any more, but it's also possible that it's not too selective and we do care about partition-wise join. So I don't think that the case that the patch fixes is something that can ever happen, but I do think it's probably fairly rare that brings any benefit, which is why I thought that EC-based matching was an OK approach to this problem initially. Perhaps that was the wrong idea, though. Does the additional logic added by this patch have a noticeable performance cost? -- Robert Haas EDB: http://www.enterprisedb.com
