On Fri, Dec 1, 2023 at 1:55 PM li jie <ggys...@gmail.com> wrote: > > > This is just an immature idea. I haven't started to implement it yet. > > Maybe it was designed this way because there > > are key factors that I didn't consider. So I want to hear everyone's > > opinions, especially the designers of logic decoding. > > Attached is the patch I used to implement this optimization. > The main designs are as follows: > 1. Added a callback LogicalDecodeFilterByRelCB for the output plugin. > > 2. Added this callback function pgoutput_table_filter for the pgoutput plugin. > Its main implementation is based on the table filter in the > pgoutput_change function. > > 3. After constructing a change and before Queue a change into a transaction, > use RelidByRelfilenumber to obtain the relation associated with the > change, > just like obtaining the relation in the ReorderBufferProcessTXN function. > > 4. Relation may be a toast, and there is no good way to get its real > table relation > based on toast relation. Here, I get the real table oid through > toast relname, and > then get the real table relation. >
This may be helpful for the case you have mentioned but how about cases where there is nothing to filter by relation? 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. I wonder why the spilling can't be avoided with GUC logical_decoding_work_mem? -- With Regards, Amit Kapila.
