Re: max_wal_senders must die

On 20.10.2010 17:19, Tom Lane wrote:
> Greg Smith<greg(at)2ndquadrant(dot)com> writes:
>> 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.
>
>> ... 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.
>
> Quite. Josh, have you got any evidence showing that the penalty is
> only 10%? There are cases, such as COPY and ALTER TABLE, where
> you'd be looking at 2X or worse penalties, because of the existing
> optimizations that avoid writing WAL at all for operations where a
> single final fsync can serve the purpose. I'm not sure what the
> penalty for "typical" workloads is, partly because I'm not sure what
> should be considered a "typical" workload for this purpose.

Going from wal_level='minimal' to 'archivë́' incurs the penalty on
WAL-logging COPY etc. That's a big penalty. However, the difference
between wal_level='archive' and wal_level='hot_standby' should be tiny.

The big reason for separating those two in 9.0 was that it's all new
code with new ways to fail and, yes, new bugs. It's not smart to expose
people who are not interested in using hot standby to those issues. But
maybe we feel more comfortable merging 'archive' and 'hot_standby'
levels in 9.1.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com