Re: Equivalence Classes when using IN

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> There are more details of the discussion in [1], although there's
> probably lots more threads to be found if you search the archives.
> [1] https://www.postgresql.org/message-id/flat/CAKJS1f9FK_X_5HKcPcSeimy16Owe3EmPmmGsGWLcKkj_rW9s6A%40mail(dot)gmail(dot)com#CAKJS1f9FK_X_5HKcPcSeimy16Owe3EmPmmGsGWLcKkj_rW9s6A(at)mail(dot)gmail(dot)com

That thread seems to be about transitively applying inequalities
(ie, given "a = b and a < c", deduce "b < c"), which seems like a bit
of a different animal than IN. Some of the issues are similar
perhaps, but I'd think that being able to deduce "b IN somelist"
from "a = b and a IN somelist" is more valuable, simply because the
IN would typically be a much stronger constraint than an inequality.
So that idea suggests that it's more worth expending planner cycles
to chase the possibility.

I do vaguely recall discussions specifically around IN, though
I didn't have any luck finding one in the archives. There's also
the recent thread
https://www.postgresql.org/message-id/flat/CAMjNa7cC4X9YR-vAJS-jSYCajhRDvJQnN7m2sLH1wLh-_Z2bsw(at)mail(dot)gmail(dot)com
which suggests being able to simplify "a IN somelist AND
a IN someotherlist". If we wanted to do that, making the
"lists" be treatable as eclass members would be a good
place to start, because that would naturally result in
intersect-able lists ending up in the same eclass.

regards, tom lane