Tom Lane wrote: > "Victor Y. Yegorov" <[EMAIL PROTECTED]> writes: > > If I have on-disk bitmap > > ON (a, b, c) > > will the planner pick an index scan for > > WHERE a = 42 AND b = 'foo' > > (i.e. only part of the index attributes are involved)? Any modifications > > needed to achieve this functionality? > > 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
