Hi, On 2020-06-08 14:58:03 -0400, Robert Haas wrote: > On Mon, Jun 8, 2020 at 1:16 PM Alvaro Herrera <alvhe...@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?
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