Re: Refactoring the API for amgetmulti

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Refactoring the API for amgetmulti
Дата
Msg-id 2299.1153928221@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Refactoring the API for amgetmulti  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Refactoring the API for amgetmulti  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] Resurrecting per-page cleaner for btree
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: pgbench enhancements