pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: mark@mark.mielke.cc
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Jie Zhang <jzhang@greenplum.com>
Cc: Hannu Krosing <hannu@skype.net>
Cc: Gavin Sherry <swm@linuxworld.com.au>
Cc: pgsql-hackers@postgresql.org, Luke Lonergan <LLonergan@greenplum.com>
Subject: Re: On-disk bitmap index patch
Date: Tue, 25 Jul 2006 01:08:55 -0400
Message-ID: <20060725050855.GA31414@mark.mielke.cc> (raw)
In-Reply-To: <5085.1153802202@sss.pgh.pa.us>
References: <C0EAB84F.8FB4%jzhang@greenplum.com>
	<200607250104.k6P14St25388@momjian.us>
	<20060725015805.GA30087@mark.mielke.cc>
	<5085.1153802202@sss.pgh.pa.us>

On Tue, Jul 25, 2006 at 12:36:42AM -0400, Tom Lane wrote:
> mark@mark.mielke.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@mielke.cc / markm@ncf.ca / markm@nortel.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/




view thread (52+ messages)  latest in thread

Message-ID: <20060725050855.GA31414@mark.mielke.cc>
Permalink:  ../20060725050855.GA31414@mark.mielke.cc/
Also on:    postgresql.org/message-id/20060725050855.GA31414@mark.mielke.cc

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: mark@mark.mielke.cc, tgl@sss.pgh.pa.us, bruce@momjian.us, jzhang@greenplum.com, hannu@skype.net, swm@linuxworld.com.au, LLonergan@greenplum.com
  Subject: Re: On-disk bitmap index patch
  In-Reply-To: <20060725050855.GA31414@mark.mielke.cc>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox