On K, 2004-10-20 at 03:03, Simon Riggs wrote: > Well, thats the best one yet. That's the solution, if ever I heard it. > > The reduction in bitmap size makes their use much safer. Size matters, since > we're likely to start using these techniques on very large databases, which > imply obviously have very large CTID lists. The problem with guessing the > number of rows is you're never too sure whether its worth the startup > overhead of using the bitmap technique. ....my next question was going to > be, so how will you know when to use the technique? > > Hmmm....think....you'd need to be clear that the cost of scanning a block > didn't make the whole thing impractical. Generally, since we're using this > technique to access infrequent row combinations, we'd be looking at no more > than one row per block usually anyway. So the technique is still I/O bound - > a bit extra post I/O cpu work won't hurt much. OK, cool.
I still think that an initial implementation could be done with "a plain bitmap" kind of bitmap, if we are content with storing one bit per page only - a simple page bitmap for 1TB table with 8kB pages takes only 16 MB, and that's backends private memory not more scarce shared memory. It takes only 4mb for 32kb pages. I guess that anyone working with terabyte size tables can afford a few megabytes of RAM for query processing. ---------------- Hannu ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
