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

From: li jie <ggysxcq(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Date: 2023-12-04 02:01:43
Message-ID: CAGfChW47GPhmrejPdg8rp18P0OeP4bDEgJYX88CYnxqcS-5z9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message li jie 2023-12-04 02:05:58 Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Previous Message Anton A. Melnikov 2023-12-04 01:49:59 Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.