| From: | Andrew - Supernews <andrew+nonews(at)supernews(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Scaling SELECT:s with the number of disks on a stripe |
| Date: | 2007-04-04 12:03:20 |
| Message-ID: | slrnf17508.2i67.andrew+nonews@atlantis.supernews.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 2007-04-04, Peter Schuller <peter(dot)schuller(at)infidyne(dot)com> wrote:
>> The next question then is whether anything in your postgres configuration
>> is preventing it getting useful performance from the OS. What settings
>> have you changed in postgresql.conf?
>
> The only options not commented out are the following (it's not even
> tweaked for buffer sizes and such, since in this case I am not
> interested in things like sort performance and cache locality other
> than as an afterthought):
>
> shared_buffers = 1000
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.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arnau | 2007-04-04 12:35:56 | Re: Equivalents in PostgreSQL of MySQL's "ENGINE=MEMORY" "MAX_ROWS=1000" |
| Previous Message | Dave Cramer | 2007-04-04 11:52:48 | Re: Scaling SELECT:s with the number of disks on a stripe |