Re: Refactoring the API for amgetmulti
От | Martijn van Oosterhout |
---|---|
Тема | Re: Refactoring the API for amgetmulti |
Дата | |
Msg-id | 20060726155431.GB32377@svana.org обсуждение исходный текст |
Ответ на | Re: Refactoring the API for amgetmulti (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Refactoring the API for amgetmulti
|
Список | pgsql-hackers |
On Wed, Jul 26, 2006 at 11:37:01AM -0400, Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > 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. Yeah, off the top of my head I can't think of any other uses. Since you're not able to do backwards scans with getmulti, there's really no advantage at all over stuff into a bitmap: you could never uses it anywhere requiring order anyway. I've considered whether it's worthwhile going to other way: getting the IndexScan executer node to uses getmulti to reduce index AM overhead. But that requires backward scan support also... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-hackers по дате отправления: