From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Luke Lonergan <llonergan@greenplum.com>
Cc: William Yu <wyu@talisys.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Hardware/OS recommendations for large databases (
Date: Wed, 16 Nov 2005 11:54:34 -0600
Message-ID: <1132163674.3582.81.camel@state.g2switchworks.com> (raw)
In-Reply-To: <BFA0B0AE.13D4E%llonergan@greenplum.com>
References: <BFA0B0AE.13D4E%llonergan@greenplum.com>
On Wed, 2005-11-16 at 11:47, Luke Lonergan wrote:
> Scott,
Some cutting for clarity... I agree on the OLTP versus OLAP
discussion.
> Here are the facts so far:
> * Postgres can only use 1 CPU on each query
> * Postgres I/O for sequential scan is CPU limited to 110-120
> MB/s on the fastest modern CPUs
> * Postgres disk-based sort speed is 1/10 or more slower than
> commercial databases and memory doesn’t improve it (much)
But PostgreSQL only spills to disk if the data set won't fit into the
amount of memory allocated by working_mem / sort_mem. And for most
Business analysis stuff, this can be quite large, and you can even crank
it up for a single query.
I've written reports that were horrifically slow, hitting the disk and
all, and I upped sort_mem to hundreds of megabytes until it fit into
memory, and suddenly, a slow query is running factors faster than
before.
Or did you mean something else by "disk base sort speed"???
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: smarlowe@g2switchworks.com, llonergan@greenplum.com, wyu@talisys.com
Subject: Re: Hardware/OS recommendations for large databases (
In-Reply-To: <1132163674.3582.81.camel@state.g2switchworks.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox