Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > I've started reading the GIT patch to see if I can help with the review.
> As the patch stands, I tried to keep it as non-invasive as possible,
> with minimum changes to existing APIs. That's because in the winter we
> were discussing changes to the indexam API to support the bitmap index
> am, and also GIT. I wanted to just have a patch to do performance
> testing with, without getting into the API changes.
Hmm, do say, doesn't it seem like the lack of feedback and the failed
bitmap patch played against final development of this patch? 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.
Of the three proposals you suggest, I think the first one
> 1. A grouped index tuple contains a bitmap of offsetnumbers,
> representing a bunch of heap tuples stored on the same heap page, that
> all have a key between the key stored on the index tuple and the next
> index tuple. We don't keep track of the ordering of the heap tuples
> represented by one group index tuple. When doing a normal, non-bitmap,
> index scan, they need to be sorted. This is what the patch currently
> implements.
makes the most sense -- the index is keep simple and fast, and doing the
sorting during an indexscan seems a perfectly acceptable compromise,
knowing that the amount of tuples possible returned for sort is limited
by the heap blocksize.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Everything that I think about is more fascinating than the crap in your head." (Dogbert's
interpretationof blogger philosophy)
