Re: PostgreSQL TPC-H test result?

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

In response to

Browse pgsql-general by date

  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;