On 20.10.2010 17:19, Tom Lane wrote:
Greg Smith<g...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
