On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Magnus Hagander <mag...@hagander.net> writes:
> > Yes, these changes will increase some of the default overhead. My
> argument
> > against that is that anybody who actually cares about that overhead is
> > going to be tuning their database *anyway*, so they can just change
> things
> > back to the old defaults.
> > So, I suggest the following changes to the defaults:
> > wal_level=hot_standby
> > max_wal_senders=10
> > max_replication_slots=10
> It would be easier to sell this if we had some numbers for the amount of
> overhead it would add for people *not* using the features.  I do not think
> I've ever seen, eg, pgbench results with different wal_level and all else
> the same.

That's going to be extremely workload dependent. For example, I'd expect
the overhead to be very close to 0 on a pgbench SELECT only benchmark :)

The big thing is, IIRC, that we turn off the optimizations in
min_wal_level. *most* people will see no impact of their regular
application runtime from that, but it might definitely have an effect on
data loads and such. For normal runtime, there should be very close to zero
difference, no?

> > And in pg_hba.conf, we enable the replication connections by default for
> > the superuser on local/localhost.
> Potential security implications?
Since we already allow superuser login from that same target, I don't see

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Reply via email to