Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group