Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I do notice that createplan.c makes some effort to get rid of filter >> conditions that are provably true when the index conditions are. >> Doesn't look like it considers the reverse direction. Not sure if >> that's missing a bet.
> That actually strikes me as a less likely condition to have in the > general case, isn't it? Wouldn't that only happen if the index > predicate and the user predicate are identical, because otherwise we > either can't use the index or we must keep the user's predicate because > it will only be satisfied in a subset of cases? Well, remember that the planner's idea of an ideal situation is to not have any filter conditions, not to not have any index (a/k/a recheck) conditions. It's going to try to put as much load as it can on the index condition side of things, and that gives rise to the need for rechecks. It seems like there might be some mileage to be gained by reversing the proof direction here, and having it get rid of recheck conditions that are implied by filter conditions rather than vice versa. I'm not quite convinced though, and I'm also not sure how hard it would be to mechanize. A lot of that code is shared between the bitmap and plain-indexscan cases, which could make it tricky to not break the plain-indexscan case. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers