Bruce Momjian <pgman@candle.pha.pa.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. This is true for btree and gist indexes,
> > so I suppose we'd need to introduce a pg_am column that tells what to
> > do.
>
> 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
>
> For an index on col1,col2,col3, and a WHERE clause of col1 = 5 and
> col3 = 9, spin though the index checking for col1 and col3 matches,
> rather than just col1; also called skip-scanning.
That TODO is something else.
Though it is related in that it is another example of why the existing code is
too simplistic and will eventually need to be enhanced. Not only would bitmap
indexes and (possibly) gist indexes, but even btree indexes would need to do
so if this TODO were implemented.
--
greg