Date: Mon, 8 Jun 2020 15:27:56 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	Magnus Hagander <magnus@hagander.net>,
	Michael Paquier <michael@paquier.xyz>,
	Amit Kapila <amit.kapila16@gmail.com>,
	David Fetter <david@fetter.org>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Bump default wal_level to logical
Message-ID: <20200608192756.GA16651@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+TgmoYHptTXESRz0BAG3NXORs98Ty3GTb4rD02FTGNfhFre3w@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Jun-08, Robert Haas wrote:

> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > I think it's reasonable to push our default limits for slots,
> > walsenders, max_bgworkers etc a lot higher than current value (say 10 ->
> > 100).  An unused slot wastes essentially no resources; an unused
> > walsender is just one PGPROC entry.  If we did that, and also allowed
> > wal_level to be changed on the fly, we wouldn't need to restart in order
> > to enable logical replication, so there would be little or no pressure
> > to change the wal_level default.
> 
> Wouldn't having a whole bunch of extra PGPROC entries have negative
> implications for the performance of GetSnapshotData() and other things
> that don't scale well at high connection counts?

On a quantum-mechanics level, sure, but after Andres's snapshot
scalability patches, will it be measurable?  (Besides, if your workload
is so high that you're measurably affected by the additional unused
PGPROC entries, you can always tune it lower.)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services