Re: Postgresql on an AMD64 machine

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)surnet(dot)cl>
Cc: Donald Courtney <Donald(dot)Courtney(at)Sun(dot)COM>, Tom Arthurs <tarthurs(at)jobflash(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgresql on an AMD64 machine
Date: 2005-06-07 21:11:29
Message-ID: 18285.1118178689@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Alvaro Herrera <alvherre(at)surnet(dot)cl> writes:
> This was the standard wisdom with releases previous to 8.0; I'm not sure
> if anyone confirmed to still hold after the buffer manager changes in
> 8.0 and later in 8.1 -- we saw extensive redesign of the bufmgr on both,
> so the behavior may have changed. If you wanna test, I'm sure lots of
> people here will be interested in the results.

Quite. The story at the moment is that we haven't bothered to create
support for shared memory exceeding 2Gb, because there's never been any
evidence that pushing shared_buffers up even close to that, much less
above it, was a good idea. Most people have found the "sweet spot" to
be in the range of 10K to 50K shared buffers, with performance dropping
off above that.

Obviously we'd be willing to do this work if there were convincing
evidence it'd be worth the time. A benchmark showing performance
continuing to climb with increasing shared_buffers right up to the 2Gb
limit would be reasonably convincing. I think there is 0 chance of
drawing such a graph with a pre-8.1 server, because of internal
inefficiencies in the buffer manager ... but with CVS tip the story
might be different.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2005-06-07 22:21:48 Re: slow growing table
Previous Message Michael Stone 2005-06-07 21:04:39 Re: Postgresql on an AMD64 machine