Re: [HACKERS] Replication/backup defaults
От | Tomas Vondra |
---|---|
Тема | Re: [HACKERS] Replication/backup defaults |
Дата | |
Msg-id | 577a14ff-3fbf-eab6-df2f-1c7d6a572bda@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Replication/backup defaults (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On 01/03/2017 01:34 PM, Michael Paquier wrote: > On Mon, Jan 2, 2017 at 10:55 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> In the hope of making things better in 10.0, I remove my objection. >> If people want to use wal_level = minimal they can restart their >> server and they can find that out in the release notes. >> >> Should we set wal_level = replica or wal_level = logical as the >> default for 10.0? > > replica sounds like a better default to me as most users use at > least archiving. Logical decoding is still fresh though, and its use > is not that wide. Have there been any study on its performance > impact compared to replica by the way? > I've just posted results for some benchmarks I'm running. Those are some simple pgbench tests, nothing special, and according to those results the performance impact (logical vs. replica) is negligible. I can run additional tests with other workloads, of course. While we can probably construct workloads where the difference is measurable, I'm not sure performance impact is the main concern here. As you point out, we have 'replica' since 9.0 effectively, while logical is much newer, so perhaps there are some hidden bugs? It'd be embarrassing to pick 'logical' and hurt everyone, even if they don't get any benefit from wal_level=logical. So +1 to 'replica' and allowing switching to 'logical' without restart. That should not be extremely difficult, as the main culprit seems to be max_wal_senders/max_replication_slots requiring shared memory. But with 'replica' we already have those enabled/allocated, unlike when switching from 'minimal' to 'replica'. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: