On Wed, Feb 21, 2024 at 6:25 AM Richard Guo <guofenglinux@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