Re: Best way to scan on-disk bitmaps - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Best way to scan on-disk bitmaps
Date
Msg-id 200505141631.j4EGVMm16956@candle.pha.pa.us
Whole thread Raw
In response to Re: Best way to scan on-disk bitmaps  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Best way to scan on-disk bitmaps  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Tom Lane wrote:
> "Victor Y. Yegorov" <viy@mits.lv> writes:
> > If I have on-disk bitmap
> >     ON (a, b, c)
> > will the planner pick an index scan for
> >     WHERE a = 42 AND b = 'foo'
> > (i.e. only part of the index attributes are involved)? Any modifications
> > needed to achieve this functionality?
> 
> Hmm.  That particular case will work, but the planner believes that only
> consecutive columns in the index are usable --- that is, if you have
> quals for a and c but not for b, it will think that the condition for c
> isn't usable with the index.  This is true for btree and gist indexes,
> so I suppose we'd need to introduce a pg_am column that tells what to
> do.

We do have a TODO for this:

* Use index to restrict rows returned by multi-key index when used with non-consecutive keys to reduce heap accesses
 For an index on col1,col2,col3, and a WHERE clause of col1 = 5 and col3 = 9, spin though the index checking for col1
andcol3 matches, rather than just col1; also called skip-scanning.
 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Server instrumentation for 8.1
Next
From: Andrew Dunstan
Date:
Subject: alternate regression dbs?