Re: Optimization of vacuum for logical replication - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Optimization of vacuum for logical replication
Date
Msg-id 5e8de371-f32e-68f4-9a7c-f6756a6630a0@postgrespro.ru
Whole thread Raw
In response to Re: Optimization of vacuum for logical replication  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers

On 22.08.2019 6:13, Kyotaro Horiguchi wrote:
> Hello.
>
> At Wed, 21 Aug 2019 18:06:52 +0300, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote in
<968fc591-51d3-fd74-8a55-40aa770baa3a@postgrespro.ru>
>> Ok, you convinced me that there are cases when people want to combine
>> logical replication with streaming replication without slot.
>> But is it acceptable to have GUC variable (disabled by default) which
>> allows to use this optimizations?
> The odds are quite high. Couldn't we introduce a new wal_level
> value instead?
>
> wal_level = logical_only
>
>
> I think this thread shows that logical replication no longer is a
> superset(?) of physical replication.  I thougt that we might be
> able to change wal_level from scalar to bitmap but it breaks
> backward compatibility..
>
> regards.
>
I think that introducing new wal_level is good idea.
There are a lot of other places (except vacuum) where we insert in the 
log information which is not needed for logical decoding.
Instead of changing all places in code where this information is 
inserted, we can filter it at xlog level (xlog.c).
My only concern is how much incompatibilities will be caused by 
introducing new wal level.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Why overhead of SPI is so large?
Next
From: Surafel Temesgen
Date:
Subject: Re: FETCH FIRST clause PERCENT option