I see, this makes sense. Thanks!
On Thu, May 14, 2009 at 12:36 PM, MARK CALLAGHAN <mdcallag@stripped> wrote:
> 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>
>>> > 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
>>> >> from the key. In this case the index is essentially useless - I
>>> >> to do a full table scan. I don't see how one could implement an
>>> >> 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
> that context.
> 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
> Mark Callaghan