Magnus Hagander wrote:
>> On 30.11.2012 21:02, Andres Freund wrote:
>>> 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.
> I'm with Heikki on the -1 on this. It's certainly unexpected to have
> the slave affect the master by default - people will expect the master
> to be independent.
> +1. Having your reporting query time out *shows you* the problem.
> Having the master bloat for you won't show the problem until later -
> when it's much bigger, and it's much more pain to recover from.
I couldn't agree more.
There are different requirements, and there will always be
people who need to change the defaults, but the way it is is
the safest in my opinion.
In response to
pgsql-hackers by date
|Next:||From: Erik Rijkers||Date: 2012-12-01 11:22:56|
|Subject: Re: WIP: index support for regexp search|
|Previous:||From: Amit Kapila||Date: 2012-12-01 08:09:04|
|Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL|