Re: Bump default wal_level to logical

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Bump default wal_level to logical
Дата
Msg-id CABUevEwL1P3ZDC=6N6NbbtCkbgnt9JnO2jUFyme6NyRdvSebvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bump default wal_level to logical  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Bump default wal_level to logical  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: Bump default wal_level to logical  (David Fetter <david@fetter.org>)
Re: Bump default wal_level to logical  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


On Mon, Jun 8, 2020 at 8:46 AM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Jun 08, 2020 at 11:59:14AM +0530, Amit Kapila wrote:
> I think we should first do performance testing to see what is the
> overhead of making this default.  I think pgbench read-write at
> various scale factors would be a good starting point.  Also, we should
> see how much additional WAL it generates as compared to current
> default.

+1.  I recall that changing wal_level to logical has been discussed in
the past and performance was the actual take to debate on.

That was at least the discussion (long-going and multi-repeated) before we upped it from minimal to replica. There were some pretty extensive benchmarking done to prove that the difference was very small, and this was weighed against the ability to take basic backups of the system (which arguably is more important than being able to do logical replication).

I agree that we should consider changing it *if* it does not come with a substantial overhead, but that has to be shown.

Of course, what would be even neater would be if it could be changed so you don't have to bounce the server to change the wal_level. That's a bigger change though, but perhaps it is now possible once we have the "global barriers" in 13?

--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Read access for pg_monitor to pg_replication_origin_status view
Следующее
От: Justin Pryzby
Дата:
Сообщение: should CREATE INDEX ON partitioned_table callPreventInTransactionBlock() ?