| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Alan Stange <stange(at)rentec(dot)com>, "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-14 15:52:05 |
| Message-ID: | 4861.1237045925@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Mar 13, 2009 at 10:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I assume you meant effective_io_concurrency. We'd still need a special
>> case because the default is currently hard-wired at 1, not 0, if
>> configure thinks the function exists.
> I think 1 should mean no prefetching, rather than 0.
No, 1 means "prefetch a single block ahead". It doesn't involve I/O
concurrency in the sense of multiple I/O requests being processed at
once; what it does give you is CPU vs I/O concurrency. 0 shuts that
down and returns the system to pre-8.4 behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-03-14 16:09:49 | Re: Proposal of tunable fix for scalability of 8.4 |
| Previous Message | decibel | 2009-03-14 15:40:18 | Re: Proposal of tunable fix for scalability of 8.4 |