Re: Optimization of vacuum for logical replication

Поиск
Список
Период
Сортировка
От Konstantin Knizhnik
Тема Re: Optimization of vacuum for logical replication
Дата
Msg-id 5e8de371-f32e-68f4-9a7c-f6756a6630a0@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Optimization of vacuum for logical replication  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Why overhead of SPI is so large?
Следующее
От: Surafel Temesgen
Дата:
Сообщение: Re: FETCH FIRST clause PERCENT option