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

From Tom Lane
Subject Re: Best way to scan on-disk bitmaps
Date
Msg-id 12737.1115934006@sss.pgh.pa.us
Whole thread Raw
In response to Re: Best way to scan on-disk bitmaps  ("Victor Y. Yegorov" <viy@mits.lv>)
Responses Re: Best way to scan on-disk bitmaps  (Greg Stark <gsstark@mit.edu>)
Re: Best way to scan on-disk bitmaps  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Best way to scan on-disk bitmaps  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
"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.

[ thinks some more ... ]

Plan B would be to remove that restriction and teach btree and gist to
cope.  While a btree couldn't use a nonconsecutive restriction as part
of its where-to-scan logic, I don't see any good reason why it couldn't
still perform the test before returning the TID, thus possibly saving a
trip to the heap.  Offhand it seems this should be true of gist as well,
but I don't know that code well enough to be sure.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Victor Y. Yegorov"
Date:
Subject: Re: Best way to scan on-disk bitmaps
Next
From: Oliver Jowett
Date:
Subject: Re: SQL_ASCII vs. 7-bit ASCII encodings