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
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. |