Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > We have already figured out that the user's predicate results in a > > subset of the index's or we wouldn't be able to use that index though, > > right? Do we really need to spend cycles re-discovering that? Are > > there cases where we actually need the index's predicate to ever be > > included for correctness..? > > In a bitmap indexscan, yes, because the entire point of the recheck > condition is that we're going to scan a whole page and possibly see > tuples that don't satisfy the index predicate at all.
I understand the point of the recheck condition being that we might see tuples that don't satisfy either the index predicate or the user's predicate, but that isn't the point- to even consider using that index we must have already realized that the user's predicate will only be satisfied in a subset of cases when the index predicate predicate will be satisfied, making any check of the index predicate necessairly always true. > Another point > that's mentioned in the comments in createplan.c is that if you're > considering the result of a BitmapOr or BitmapAnd, there's not necessarily > a single index involved so it's much harder to reason about which part > of the qual is an index predicate. We must be pulling the index's predicate to be able to put it into the Recheck condition in the first place. What I'm arguing is that once we've decided that we're able to use an index X, because the values which the user's predicate will satisfy is a subset of those which the index's predicate will satisfy, then we can entirely forget about the index's predicate as being redundant to the user's. I don't see anything about a BitmapAnd or BitmapOr being relevant to that. We will always need to check the user's predicate against the tuples being returned from the Bitmap Heap Scan, unless by chance it matches the index's predicate exactly *and* we have an entirely exact match bitmap without any lossy parts. > 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? Thanks! Stephen
Description: Digital signature