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