On 30.11.2012 21:02, Andres Freund wrote:
Hi,
The subject says it all.
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting conflicts
because of vacuum is rather confusing.
In the workloads where it might not be a good idea (very long queries on
the standby, many dead tuples on the primary) you need to think very
carefuly about the strategy of avoiding conflicts anyway, and explicit
configuration is required as well.
Does anybody have an argument against changing the default value?
-1. By default, I would expect a standby server to not have any
meaningful impact on the performance of the master. With hot standby
feedback, you can bloat the master very badly if you're not careful.
Think of someone setting up a test server, by setting it up as a standby
from the master. Now, when someone holds a transaction open in the test
server, you get bloat in the master. Or if you set up a standby for
reporting purposes - a very common use case - you would not expect a
long running ad-hoc query in the standby to bloat the master. That's
precisely why you set up such a standby in the first place.
You could of course still turn it off, but you would have to know about
it in the first place. I think it's a reasonable assumption that a
standby does *not* affect the master (aside from the bandwidth and disk
space required to retain/ship the WAL). If you have to remember to
explicitly set a GUC to get that behavior, that's a pretty big gotcha.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
