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 по дате отправления: