Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > Hmm, do say, doesn't it seem like the lack of feedback and the failed
> > bitmap patch played against final development of this patch?
> Yes :(. That's a one reason why I tried to help with the review of that
> > At this
> > point I feel like the patch still needs some work and reshuffling before
> > it is in an acceptable state. The fact that there are some API changes
> > for which the patch needs to be adjusted makes me feel like we should
> > put this patch on hold for 8.4. So we would first get the API changes
> > discussed and done and then adapt this patch to them.
> I hate to say it but I agree. Getting the API changes discussed and
> committed was my plan in February/March. Unfortunately it didn't happen
> back then.
> There's a few capabilities we need from the new API:
> 1. Support for candidate matches. Because a clustered index doesn't
> contain the key for every heap tuple, when you search for a value we
> don't know exactly which ones match. Instead, you get a bunch of
> candidate matches, which need to be rechecked after fetching the heap
> tuple. Oleg & Teodor pointed out that GiST could use the capability as
> well. I also proposed a while ago to change the hash index
> implementation so that it doesn't store the index key in the index, but
> just the hash of it. That again would need the support for candidate
> matches. And there's range-encoded bitmap indexes, if we implement them
> in a more distant future.
Well, then should we return to the review of your 'bitmapscan changes'
patch ? I've posted a version which applies (or applied to the cvs head
at the time of post) cleanly there:
> 2. Support to sort the heap tuples represented by one index tuple, in
> normal index scans, if we go with alternative 1. Or support to do binary
> searches over them, if we go with alternative 2 or 3. As the patch
> stands, the sorting is done within b-tree, but that's quite ugly.
Alexey Klyukin http://www.commandprompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?