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
> *) 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?
In response to
pgsql-performance by date
|Next:||From: Tyler Hildebrandt||Date: 2010-05-25 09:59:43|
|Subject: Query timing increased from 3s to 55s when used as a functioninstead of select|
|Previous:||From: Joachim Worringen||Date: 2010-05-25 09:52:20|
|Subject: Re: performance of temporary vs. regular tables|