Re: Refactoring the API for amgetmulti - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring the API for amgetmulti
Date
Msg-id 2299.1153928221@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactoring the API for amgetmulti  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Refactoring the API for amgetmulti  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
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 come back till you're done"?

> 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 of TIDs, submitting
> all the read requests in parallel and then waiting on them. What you
> lose by storing straight into bitmaps is the *order*.

Right, part of the reason for defining getmulti as it is was the idea
of preserving flexibility.  However it's not apparent that that
flexibility is buying us anything.

What I'm actually thinking of doing is replacing amgetmulti with an
"amgetbitmap" entry point.  We could leave amgetmulti in place alongside
that if there's any prospect of near-term use for it.  But I kinda doubt
there will be, so I'm inclined to remove it instead.  We can always
re-add it from the CVS archives if a use appears.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] Resurrecting per-page cleaner for btree
Next
From: Tatsuo Ishii
Date:
Subject: Re: pgbench enhancements