Re: shared_buffers advice

From: Konrad Garus <konrad(dot)garus(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Paul McGarry <paul(at)paulmcgarry(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: shared_buffers advice
Date: 2010-05-25 09:58:24
Message-ID: AANLkTim6FolMPvH997nW5FSciJtR6VJevEsN0gE43clO@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

2010/5/24 Merlin Moncure <mmoncure(at)gmail(dot)com>:

> *) a page fault to disk is a much bigger deal than a fault to pg cache
> vs os/ cache.

That was my impression. That's why I did not touch our 2/16 GB setting
right away. I guess that 2 more gigabytes in OS cache is better than 2
more (duplicated) gigabytes in PG shared_buffers. In our case 2 GB
shared_buffers appears to be enough to avoid thrashing between OS and
PG.

> *) shared_buffers is one of the _least_ important performance settings
> in postgresql.conf
>
> Many settings, like work_mem, planner tweaks, commit settings,
> autovacuum settings

Can you recommend any sources on these parameters, especially commit
settings and planner tweaks?

Thank you so much for the whole answer! Not only it addresses the
immediate question, but also many of the unasked that I had in the
back of my head. It's brief and gives a broad view over all the
performance concerns. It should be part of documentation or the first
page of performance wiki. Have you copied it from somewhere?

--
Konrad Garus

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tyler Hildebrandt 2010-05-25 09:59:43 Query timing increased from 3s to 55s when used as a function instead of select
Previous Message Joachim Worringen 2010-05-25 09:52:20 Re: performance of temporary vs. regular tables