Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 - Mailing list pgsql-performance

From Tom Lane
Subject Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Date
Msg-id 26666.1236996376@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4  (Robert Haas <robertmhaas@gmail.com>)
Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4  (Bruce Momjian <bruce@momjian.us>)
List pgsql-performance
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.

            regards, tom lane

pgsql-performance by date:

Previous
From: Gregory Stark
Date:
Subject: Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Next
From: Vamsidhar Thummala
Date:
Subject: Re: Hash Join performance