Re: Bump default wal_level to logical - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Bump default wal_level to logical
Date
Msg-id CABUevEwL1P3ZDC=6N6NbbtCkbgnt9JnO2jUFyme6NyRdvSebvw@mail.gmail.com
Whole thread Raw
In response to Re: Bump default wal_level to logical  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Bump default wal_level to logical
Re: Bump default wal_level to logical
Re: Bump default wal_level to logical
List 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 by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Read access for pg_monitor to pg_replication_origin_status view
Next
From: Justin Pryzby
Date:
Subject: should CREATE INDEX ON partitioned_table callPreventInTransactionBlock() ?