Greg Stark wrote: > > Tom Lane <[EMAIL PROTECTED]> writes: > > > In any case, this discussion is predicated on the assumption that the > > operations involving the bitmap are a significant fraction of the total > > time, which I think is quite uncertain. Until we build it and profile > > it, we won't know that. > > The other thought I had was that it would be difficult to tell when to follow > this path. Since the main case where it wins is when the individual indexes > aren't very selective but the combination is very selective, and we don't have > inter-column correlation statistics ...
I like the idea of building in-memory bitmapped indexes. In your example, if you are restricting on A and B, and have no A,B index but an A index and B index, why wouldn't you always create an in-memory bitmapped index from indexes A and B, unless index A hits only a few rows. In fact, from the optimizer statistics, you can guess on how many bits you will hit from index A and index B, so we only have to decide if it is better to take the more restrictive index and do heap lookups for those, or scan the second index and then hit the heap. The only thing A,B combined statistics would tell you is how many heap matches you will find. The time to scan A and B indexes and create the bitmap is already guessable from the single column statistics. Also, what does an in-memory bitmapped index look like? Is it: value: bitmap... value: bitmap... with the values organized in a btree fashion? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org