| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:54:31 |
| Message-ID: | 20060726155431.GB32377@svana.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 26, 2006 at 11:37:01AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-07-26 15:59:52 | Re: Refactoring the API for amgetmulti |
| Previous Message | andrew | 2006-07-26 15:52:33 | Re: pgbench enhancements |