Re: plans for bitmap indexes?

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Chris Browne <cbbrowne(at)acm(dot)org>
Subject: Re: plans for bitmap indexes?
Date: 2004-10-19 22:38:49
Message-ID: 20041019223849.GB9211@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 19, 2004 at 11:22:31PM +0100, Simon Riggs wrote:

> I was thinking about this recently, then realised that building the bitmap
> would not be as easily, since PostgreSQL doesn't index null values. That
> would mean that the sets of CTIDs in each index would be disjoint. My
> thinking about dynamic bitmaps came from Teradata, which does index null
> values.

Huh, you are wrong. At least btree does index null values, and one
other index method does too. The other two index methods don't. What
doesn't work is using an index with the IS NULL construct, because it's
not an operator. Maybe that can be fixed by some other means ... some
parser magic perhaps.

> Or would you:
> - copy aside and sort the indexes on CTID
> - merge join them all to find matching CTIDs
> - probe into the main table

IIRC part of the trick was to build bitmaps to apply bitwise-AND/OR
operators. This allows to use multiple indexes for one scan, for
example.

I don't understand your comment about read only tables ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I call it GNU/Linux. Except the GNU/ is silent." (Ben Reiter)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-10-19 22:43:39 Re: tsearch2 windows make failure
Previous Message Andrew Dunstan 2004-10-19 22:35:16 Re: tsearch2 windows make failure