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)
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 |