| From: | Alan Stange <stange(at)rentec(dot)com> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>, Greg Smith <gsmith(at)gregsmith(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 |
| Date: | 2009-03-13 15:20:04 |
| Message-ID: | 49BA79A4.9030208@rentec.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Gregory Stark wrote:
> A minute ago I said:
>
> AFAIK Opensolaris doesn't implement posix_fadvise() so there's no benefit. It
> would be great to hear if you could catch the ear of the right people to get
> an implementation committed. Depending on how the i/o scheduler system is
> written it might not even be hard -- the Linux implementation of WILLNEED is
> all of 20 lines.
>
> I noticed after sending it that that's slightly unfair. The 20-line function
> calls another function (which calls another function) to do the real readahead
> work. That function (mm/readahead.c:__do_page_cache_readahead()) is 48 lines.
>
>
It's implemented. I'm guessing it's not what you want to see though:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/posix_fadvise.c
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2009-03-13 15:55:30 | Re: Proposal of tunable fix for scalability of 8.4 |
| Previous Message | Jignesh K. Shah | 2009-03-13 14:56:45 | Re: Proposal of tunable fix for scalability of 8.4 |