From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Brent Wood" <b(dot)wood(at)niwa(dot)co(dot)nz>, ajs(at)commandprompt(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: PostgreSQL TPC-H test result? |
Date: | 2008-09-10 00:51:43 |
Message-ID: | b42b73150809091751w4748c64fnd72e770460f4951@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Sep 9, 2008 at 3:37 PM, Martijn van Oosterhout
<kleptog(at)svana(dot)org> wrote:
> On Wed, Sep 10, 2008 at 07:16:35AM +1200, Brent Wood wrote:
>> Given the general increase in typical hardware specs these days,
>> perhaps the default pg specs could be set for higher spec systems?
>
> Given the default shmem configuration on operating systems these days,
> upping the default will likely cause postgresql to not run at all.
And it wont change the results much either. Changing shared_buffers
is very nuanced and can help or hurt performance, but it isn't tuning
in the sense it's a level you can pull to make the database 'go
faster' like magic. A lot of the obsessing about shared_buffers
resolves around the fact that remarkably few people understand how
memory works in modern operating systems.
The 'big ticket' .conf items are those that affect syncing in write
heavy enviroments (fsync, etc) and planner affecting settings
(work_mem, effective_cache_size). That said, PostgreSQL requires
very little tuning outside of the obvious tradeoffs between speed and
safety. This is an ongoing process...in the old days I had to agonize
about dealing with the stats collector...in modern terms there is much
less to 'trade off' (hopefully less still with 8.4).
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Randal T. Rioux | 2008-09-10 01:25:48 | Re: 64-bit Compile Failure on Solaris 10 with OpenSSL |
Previous Message | Tom Lane | 2008-09-10 00:46:10 | Re: syntax error on: GET DIAGNOSTICS xcount = ROW_COUNT; |