From: Peter Schuller <peter.schuller@infidyne.com>
To: andrew@supernews.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Scaling SELECT:s with the number of disks on a stripe
Date: Wed, 4 Apr 2007 19:44:48 +0200
Message-ID: <20070404174448.GA6918@hyperion.scode.org> (raw)
In-Reply-To: <slrnf17508.2i67.andrew+nonews@atlantis.supernews.net>
References: <20070330051645.GA78431@hyperion.scode.org>
<slrnf0tpnk.2i67.andrew+nonews@atlantis.supernews.net>
<20070402105355.GB57038@hyperion.scode.org>
<slrnf12dlc.2i67.andrew+nonews@atlantis.supernews.net>
<20070404060116.GA97698@hyperion.scode.org>
<slrnf17508.2i67.andrew+nonews@atlantis.supernews.net>
Hello,
> I'd always do benchmarks with a realistic value of shared_buffers (i.e.
> much higher than that).
>
> Another thought that comes to mind is that the bitmap index scan does
> depend on the size of work_mem.
>
> Try increasing your shared_buffers to a reasonable working value (say
> 10%-15% of RAM - I was testing on a machine with 4GB of RAM, using a
> shared_buffers setting of 50000), and increase work_mem to 16364, and
> see if there are any noticable changes in behaviour.
Increasing the buffer size and work_mem did have a significant
effect. I can understand it in the case of the heap scan, but I am
still surprised at the index scan. Could pg be serializing the entire
query as a result of insufficient buffers/work_mem to satisfy multiple
concurrent queries?
With both turned up, not only is the heap scan no longer visibly CPU
bound, I am seeing some nice scaling in terms of disk I/O. I have not
yet benchmarked to the point of being able to say whether it's
entirely linear, but it certainly seems to at least be approaching the
ballpark.
Thank you for the help! I guess I made a bad call not tweaking
this. My thinking was that I explicitly did not want to turn it up so
that I could benchmark the raw performance of disk I/O, rather than
having things be cached in memory more than it would already be. But
apparantly it had other side-effects I did not consider.
Thanks again,
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
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: peter.schuller@infidyne.com, andrew@supernews.com
Subject: Re: Scaling SELECT:s with the number of disks on a stripe
In-Reply-To: <20070404174448.GA6918@hyperion.scode.org>
* 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