Re: Optimization of vacuum for logical replication

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: mailings(at)oopsware(dot)de, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Optimization of vacuum for logical replication
Date: 2019-08-23 11:37:28
Message-ID: 8f5cd09d-ad80-d746-abd7-a606d17b0a38@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.08.2019 6:13, Kyotaro Horiguchi wrote:
> Hello.
>
> At Wed, 21 Aug 2019 18:06:52 +0300, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> wrote in <968fc591-51d3-fd74-8a55-40aa770baa3a(at)postgrespro(dot)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 can propose the following patch introducing new level logical_only.
I will be please to receive comments concerning adding new wal_level and
possible problems caused by it.

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

Attachment Content-Type Size
logical_only.patch text/x-patch 11.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2019-08-23 11:42:27 Re: Why overhead of SPI is so large?
Previous Message Bruce Momjian 2019-08-23 11:36:03 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)