Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
От | Robert Haas |
---|---|
Тема | Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 |
Дата | |
Msg-id | 603c8f070903131937t1c33fa97k29e7d8d07fa2e83@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 |
Список | pgsql-performance |
On Fri, Mar 13, 2009 at 10:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Gregory Stark <stark@enterprisedb.com> writes: >> Tom Lane <tgl@sss.pgh.pa.us> writes: >>> Ugh. So apparently, we actually need to special-case Solaris to not >>> believe that posix_fadvise works, or we'll waste cycles uselessly >>> calling a do-nothing function. Thanks, Sun. > >> Do we? Or do we just document that setting effective_cache_size on Solaris >> won't help? > > 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. Also there's a posix_fadvise call > in xlog.c that that parameter doesn't control anyhow. I think 1 should mean no prefetching, rather than 0. If the number of concurrent I/O requests was 0, that would mean you couldn't perform any I/O at all. ...Robert
В списке pgsql-performance по дате отправления: