| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bump default wal_level to logical |
| Date: | 2020-06-08 18:58:03 |
| Message-ID: | CA+TgmoYHptTXESRz0BAG3NXORs98Ty3GTb4rD02FTGNfhFre3w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kenneth Marshall | 2020-06-08 19:05:26 | Re: Bump default wal_level to logical |
| Previous Message | Tom Lane | 2020-06-08 17:27:50 | Re: Bump default wal_level to logical |