David Rowley <david.rowley@2ndquadrant.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.gmail.com#CAKJS1f9FK_X_5HKcPcSeimy16Owe3EmPmmGsGWLcKkj_rW9s6A@mail.gmail.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@mail.gmail.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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
