On Tue, 2006-07-25 at 18:49 -0400, Tom Lane wrote:
One of the complaints I had about the bitmap index patch was the extent
to which it wants to modify (and largely create duplicate code paths in)
the existing executor support for bitmap scans. Now maybe I'm missing
something but I don't think
On Tue, Jul 25, 2006 at 06:49:02PM -0400, Tom Lane wrote:
What if we dropped the array convention, and simply passed the tidbitmap
object to the index AM's getmulti function, with the instructions stuff
all the TIDs into this bitmap, and don't come back till you're done?
For the existing index
Martijn van Oosterhout kleptog@svana.org writes:
On Tue, Jul 25, 2006 at 06:49:02PM -0400, Tom Lane wrote:
What if we dropped the array convention, and simply passed the tidbitmap
object to the index AM's getmulti function, with the instructions stuff
all the TIDs into this bitmap, and don't
On Wed, Jul 26, 2006 at 11:37:01AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Well, my only thoughtis that this pretty means you can't use
index_getmulti for anything else. For example, when I was playing with
async i/o I was using index_getmulti to get a list
Martijn van Oosterhout kleptog@svana.org writes:
I've considered whether it's worthwhile going to other way: getting the
IndexScan executer node to uses getmulti to reduce index AM overhead.
But that requires backward scan support also...
I think Heikki got most of the low-hanging fruit
One of the complaints I had about the bitmap index patch was the extent
to which it wants to modify (and largely create duplicate code paths in)
the existing executor support for bitmap scans. Now maybe I'm missing
something but I don't think that's where the value-add of this patch is.
It
