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

Re: max_wal_senders must die

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: max_wal_senders must die
Date: 2010-10-20 05:06:31
Message-ID: 4CBE78D7.8070909@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Josh Berkus wrote:
> Well, now that you mention it, I also think that "hot standby" should be
> the default.  Yes, I know about the overhead, but I also think that the
> number of our users who want easy replication *far* outnumber the users
> who care about an extra 10% WAL overhead.
>   

I think this whole situation is similar to the resistance to increasing 
default_statistics_target.  There's additional overhead added by 
enabling both of these settings, in return for making it more likely for 
the average person to see useful behavior by default.  If things are 
rejiggered so the advanced user has to turn things off in order to get 
optimal performance when not using these features, in return for the 
newbie being more likely to get things working in basic form, that's 
probably a net win for PostgreSQL advocacy.  But much like 
default_statistics_target, there needs to be some more formal work done 
on quantifying just how bad each of these overheads really are first.  
We lost 3-7% on multiple simple benchmarks between 8.3 and 8.4[1] 
because of that retuning for ease of use on real-world workloads, and 
that's not something you want to repeat too often.

[1] http://suckit.blog.hu/2009/09/29/postgresql_history and the tests 
Jignesh did while at Sun

-- 
Greg Smith, 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us



In response to

Responses

pgsql-hackers by date

Next:From: Humair MohammedDate: 2010-10-20 06:45:57
Subject: Installer Fix on some Windows 7 64-bit Systems
Previous:From: Itagaki TakahiroDate: 2010-10-20 04:47:20
Subject: Re: Extensions, this time with a patch

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