On Thu, May 14, 2009 at 9:23 AM, Sergei Golubchik <serg@stripped> wrote:
> Hi, MARK!
> On May 14, MARK CALLAGHAN wrote:
>> On Thu, May 14, 2009 at 3:09 AM, Sergei Golubchik <serg@stripped> wrote:
>> > On May 13, Vyacheslav Akhmechet wrote:
>> >> Suppose a given key has two parts, A and B, and I build an index on
>> >> this key (by combining A and B in lexicographic order, or a similar
>> >> technique). Now, suppose index_read is called, and part A is missing
>> >> from the key. In this case the index is essentially useless - I need
>> >> to do a full table scan. I don't see how one could implement an index
>> >> to get around this.
>> >> Am I misunderstanding the purpose/semantics of keypart_map?
>> > No, you are not. Btree indexes, indeed, cannot support this feature.
>> > Bitmap indexes, I presume, can.
>> Btrees can and do support index scans in this case. Check out index
>> skip scan in Oracle.
> Yes, right.
> In btree you can do an index scan, but it won't be a range as with a
> prefix key.
> Thanks for correcting me.
No, now I understand. In the context of calls to the index scan
methods in handler.h, btree cannot support this. My statement ignored
But speaking about index skip scan and bitmap indexes, when do we get
support for them? There is some support in the optimizer for index-or
and index-and. Is there any chance that will be expanded to support
more complex predicates and costs that make bitmap indexes