From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, Jie Zhang <jzhang(at)greenplum(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
Subject: | Re: Refactoring the API for amgetmulti |
Date: | 2006-07-26 15:37:01 |
Message-ID: | 2299.1153928221@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2006-07-26 15:42:03 | Re: pgbench enhancements |
Previous Message | andrew | 2006-07-26 15:29:57 | Re: pgbench enhancements |