Mike Rylander <[EMAIL PROTECTED]> writes:
> Will the new Bitmap[Or|And] nodes work with lossy index types?
Sure. Obviously the lossy conditions need to be rechecked, and
depending on how bright the planner ends up being, that might
cause the whole WHERE to get rechecked. For example given
WHERE (x ~ y) OR (x ~~ z)
where let's suppose ~~ is a lossy operator, we could make bitmaps
of the index hits for each condition and OR them together; but once
we finally do visit the tuple I think we'll have to evaluate the
whole WHERE not just the lossy operator to be sure we are getting
the right answer.
We could *not* use a lossy index for something like a difference
condition (x ~ y AND NOT x ~~ z), but I'm not planning to support
that in the first go-round anyway.
> I seem to remember you (Tom) saying that the in-memory
> bitmaps would only be useful for btree indexes. I hope I'm
> mis-remembering... :)
I'm pretty sure I never said that. If I did, I was wrong.
> It will also keep long lists of ORs from turning what would have been
> a >10% index scan into a seq scan, yes?
It should look more attractive than the old method, yes. At some point
you still end up deciding you might as well seqscan. I'm not sure
whether the cost estimation model I put in last night gets the crossover
point right --- we'll need to get some field experience as soon as the
code is reasonably functional.
That reminds me: at least for testing purposes, it'd be a good idea
to have an additional planner "enable" switch for this plan type,
analogous to enable_seqscan and enable_indexscan. Any objections to
adding one? Should I call it "enable_bitmapscan", or can someone
think of a less ugly name?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
