David Rowley <david.rowley@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
