[EMAIL PROTECTED] ("Christan Josefsson") writes:
> So you indicate that the so called bitmap index scan, a.k.a
> in-memory bitmap indexes (right?), already adds such an
> improvement when it comes to optimized response time on large
> query sets (having the characteristics as normally used to
> identify cases where bitmap indexes improves performance like:
> low cardinality keys, large data volumes etc), so that the
> on-disk indexes are not really needed or atleast not worth wile
> implementing?
It looks very much like that may be the case...
Bitmap index scans have a somewhat different set of functionality, but
there is enough overlap that the cases where on-disk bitmap indexes
are useful (and in-memory bitmap scans aren't) look like rare edge
cases.
There may be users that see those "rare edge cases" all the time;
they'll find on-disk bitmap indexes worth having, and, possibly, worth
implementing.
But to be sure, there used to be a lot of "burning interest" in
on-disk bitmap indexes, and in-memory bitmap index scans have quenched
many of the flames...
--
"cbbrowne","@","cbbrowne.com"
http://linuxfinances.info/info/advocacy.html
">WindowsNT will not accept fecal matter in its diet... it's that simple.
I suppose that is a good ward against cannibalism." -- Nick Manka
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
