Re: On-disk bitmap index patch

I think we do know, have you reviewed the results in the briefing?

- Luke

Sent from my GoodLink synchronized handheld (www.good.com)

-----Original Message-----
From: mark(at)mark(dot)mielke(dot)cc [mailto:mark(at)mark(dot)mielke(dot)cc]
Sent: Tuesday, July 25, 2006 01:09 AM Eastern Standard Time
To: Tom Lane
Cc: Bruce Momjian; Jie Zhang; Hannu Krosing; Gavin Sherry; pgsql-hackers(at)postgresql(dot)org; Luke Lonergan
Subject: Re: [HACKERS] On-disk bitmap index patch

On Tue, Jul 25, 2006 at 12:36:42AM -0400, Tom Lane wrote:
> mark(at)mark(dot)mielke(dot)cc writes:
> > Reading 1/4, for a larger table, has a good chance of being faster than
> > reading 4/4 of the table. :-)
> Really?
>
> If you have to hit one tuple out of four, it's pretty much guaranteed
> that you will need to fetch every heap page. So using an index provides
> zero I/O savings on the heap side, and any fetches needed to read the
> index are pure cost. Now you have to demonstrate that the CPU costs
> involved in processing the index are significantly cheaper than the cost
> of just testing the WHERE qual at every heap tuple --- not a bet that's
> likely to win at a one-in-four ratio.

Haha. Of course - but that's assuming uniform spread of the values.
Next I would try clustering the table on the bitmap index... :-)

My databases aren't as large as many of yours. Most or all of them
will fit in 1 Gbytes of RAM. The I/O cost isn't substantial for these,
but the WHERE clause might be.

But yeah - we don't know. Waste of code or performance boost.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/