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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
