Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

Поиск
Список
Период
Сортировка
От li jie
Тема Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Дата
Msg-id CAGfChW47GPhmrejPdg8rp18P0OeP4bDEgJYX88CYnxqcS-5z9A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
>
> This may be helpful for the case you have mentioned but how about
> cases where there is nothing to filter by relation?

You can see the complete antecedent in the email [1]. Relation that has
not been published will also generate changes and put them into the entire
transaction group, which will increase invalid memory or disk space.

> It will add
> overhead related to the transaction start/end and others for each
> change. Currently, we do that just once for all the changes that need
> to be processed.

Yes, it will only be processed once at present. It is done when applying
each change when the transaction is committed. This patch hopes to
advance it to the time when constructing the change, and determines the
change queue into a based on whether the relation is published.

> I wonder why the spilling can't be avoided with GUC
> logical_decoding_work_mem?

Of course you can, but this will only convert disk space into memory space.
 For details, please see the case in Email [1].

Regards, lijie



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Anton A. Melnikov"
Дата:
Сообщение: Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.
Следующее
От: li jie
Дата:
Сообщение: Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding