Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-04-07 22:49:22
Message-ID: 200904072249.n37MnMt25858@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Bruce Momjian wrote:
> Tom Lane wrote:
> > Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
>
> The attached patch prevents the posix_fadvise() probe in configure on
> Solaris, and adds a comment why. I have already documented why Solaris
> can't do effective_io_concurrency.

Updated patch applied; open item removed as complete.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/rtmp/diff text/x-diff 10.6 KB

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Kirkwood 2009-04-08 07:15:28 Re: Best replication solution?
Previous Message Tom Lane 2009-04-07 19:31:55 Re: plpgsql arrays