On Mon, 14 Aug 2006, Tom Lane wrote:
> Gavin Sherry <swm@linuxworld.com.au> writes:
> > I will post an updated patch in a few days time.
>
> OK. Do you want me to work on the discussed amgetmulti change, or would
> that just be joggling your elbow at the moment?
Yes, that would be joggling ;).
The approach I am taking is more or less the one you proposed a few weeks
ago. Namely, to pass the bitmap object as an argument to amgetmulti and
have the routine fill it in as it sees fit.
There is some trickiness, however.
One of the main reasons for the uglification of the executor in Jie's
original patch was that she wanted to avoid the inefficiency of
translating the on disk bitmap representation to the TID bitmap
representation. If the plan calls for a straight on disk
bitmap read or AND/ORing together a few on-disk bitmaps this is justified.
If we're AND/ORing together an ondisk bitmap read and a TID bitmap scan of
a btree, we're in trouble. In this case, the existing code implements the
current semantics of amgetmulti.
What I am doing is treating the bitmap object as opaque, storing the data
in the format the AM wants, and providing a 'translate to TID bitmap'
routine (trivial for btree).
Do you have any thoughts on this?
Thanks,
Gavin