Re: Best way to scan on-disk bitmaps

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>> Hmm. That particular case will work, but the planner believes that only
>>> consecutive columns in the index are usable --- that is, if you have
>>> quals for a and c but not for b, it will think that the condition for c
>>> isn't usable with the index.
>>
>> We do have a TODO for this:
>>
>> * Use index to restrict rows returned by multi-key index when used with
>> non-consecutive keys to reduce heap accesses

> That TODO is something else.

No, I think Bruce is right --- it's essentially the same thing. It
certainly would be a good idea to change btrees to work like that,
if we are going to modify the planner to relax the restriction for
other index types.

I think it would be easy to change the planner and btree to handle
this (where "easy" means "I remember where all the skeletons are
buried"). But I don't know the gist code hardly at all. Can anyone
offer an informed opinion on whether gist can handle this now, and
if not what it would take to handle it?

(hash and rtree are not at issue since they don't support multi-key
indexes.)

regards, tom lane