Re: PostgreSQL TPC-H test result?

From: Andrew Sullivan <ajs(at)commandprompt(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: PostgreSQL TPC-H test result?
Date: 2008-09-09 20:07:56
Message-ID: 20080909200756.GD60300@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Sep 10, 2008 at 07:16:35AM +1200, Brent Wood wrote:
> Pg does itself no favours by sticking with such pessimistic
> defaults, and a novice user wanting to try it out will find tweaking
> the pg configuration files for performance quite complicated.

You do know that at install time, Pg does some elementary
investigation of the system to see what it can set its defaults to,
right?

In addition, every time this comes up I find it perplexing. The idea
seems to be that "novices" in databases should be excused from
learning about their system and should expect a nearly-optimally tuned
system out of the box. But there are so many variables involved in
database tuning as to make such a claim hard to swallow. For instance
. . .

> fits their system best? I figure (somewhat simplistically) that most
> settings are more related to available memory than anything else, so

. . . your figuring here is indeed simplistic. Every day I see
requests for help from people who have followed the rule of thumb "1/4
of memory for shared_buffers", except that they're also running
apache+jakarta, MySQL, and a mail server on the same box. They wonder
why the stock advice is so wrong. It's wrong because a
general-purpose tool is almost never going to come pre-set for every
possible workload you might want to throw at it. So even "how much
memory" there is on the machine is a question that is harder to answer
than it might seem. Disk layout, data access patterns, even the
filesystem you choose can make significant differences in how the
system performs.

Finally, part of the reason people make these claims is because they
tend to hold Postgres up against toy systems that are _not_ designed
to scale up. A certain well known database product, for instance, has
been struggling for the last several years to turn itself into a
full-featured, high-volume, safe transactional system. But the seams
keep showing, because it just wasn't designed for this workload in the
first place. But it sure is fast out of the box on a single-user
system!

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Darren Weber 2008-09-09 20:14:44 Re: OS X library path issues for libpq (ver 8.3)
Previous Message Tom Lane 2008-09-09 19:57:20 Re: Various intermittent bugs/instability - how to debug?