Re: Refactoring the API for amgetmulti

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 that's where the value-add of this patch is.

Agreed

> 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 AMs this'd be only trivially different, but it
> should result in some fractional savings of call overhead when scanning
> a large number of index entries.

Good idea.

> But for a bitmap index this is considerably more interesting, because
> it could stuff its data into the tidbitmap without the overhead of
> converting to an explicit array-of-TID format. In particular we could
> imagine adding some entry points to tidbitmap.c that accept data in a
> more friendly format, and that would all be between tidbitmap.c and the
> bitmap index AM, without the need to invade large swaths of the executor
> to make it happen.
>
> Comments? For the existing AMs this is a pretty trivial change, and
> I'd be willing to commit to making it happen before feature freeze if
> it seems useful.

Bitmap indexes are worth having, but they must be well integrated.

This sounds like the way to go.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com