Re: Bump default wal_level to logical

Hi,

On 2020-06-08 14:58:03 -0400, Robert Haas wrote:
> On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)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?

Some things yes, but I don't think it should have a significant effect
on GetSnapshotData():

We currently don't touch unused PGPROCs for it (by virtue of
procArray->pgprocnos), and we wouldn't with my proposed / pending
changes (because the relevant arrays contain data for connected backends
at the "front").
You can have some effect if you have temporary spikes to very high
connection counts, and then reduce that again. That can lead to a lot of
unused PGXACT entries being interleaved with used ones, leading to
higher cache miss ratios (data cache as well as tlb). But that cannot
become a problem without those PGPROCs ever being used, because IIRC we
otherwise ensure they're used "densely".

There are a few places where we actually look over all PGPROCs, or size
resources according to that, but I think most of those shouldn't be in
hot paths.

There are also effects like the lock hashtables being sized larger,
which then can reduce the cache hit ratio. I guess we could check
whether it'd make sense to charge less than max_locks_per_transaction
for everything but user processes, but I'm a bit doubtful it's worth it.

Greetings,

Andres Freund