Re: Inserting 8MB bytea: just 25% of disk perf used? - Mailing list pgsql-performance

From Greg Smith
Subject Re: Inserting 8MB bytea: just 25% of disk perf used?
Date
Msg-id 4B5F6667.1010308@2ndquadrant.com
Whole thread Raw
In response to Re: Inserting 8MB bytea: just 25% of disk perf used?  (Scott Carey <scott@richrelevance.com>)
List pgsql-performance
Scott Carey wrote:
#bgwriter_delay=200ms
#bgwriter_lru_percent=1.0
#bgwriter_lru_maxpages=5
#bgwriter_all_percent=0.333
#bgwriter_all_maxpages=5
#checkpoint_segments=3
#checkpoint_timeout=5min
#checkpoint_warning=30s   
Check out this for info on these parameters
http://wiki.postgresql.org/wiki/User:Gsmith  (Is there a better link Greg?) 

Nope.  I started working on that back when I had some hope that it was possible to improve the background writer in PostgreSQL 8.2 without completely gutting it and starting over.  The 8.3 development work proved that idea was mistaken, which meant historical trivia about how the ineffective 8.2 version worked wasn't worth cleaning up to presentation quality anymore.  Stuck it on my personal page on the wiki just so I didn't lose it and could point at it, never developed into a proper article.

Generally, my advice for people running 8.2 is to turn the background writer off altogether:

bgwriter_lru_maxpages=0
bgwriter_all_maxpages=0

Because what is there by default isn't enough to really work, and if you crank it up enough to do something useful it will waste a lot resources.  It's possible with careful study to find a useful middle ground--I know Kevin Grittner accomplished that on their 8.2 install, and I did it once in a way that wasn't horrible--but you're unlikely to just get one easily.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com

pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: New server to improve performance on our large and busy DB - advice?
Next
From: Greg Smith
Date:
Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)