Re: Avoid distributing new catalog snapshot again for the transaction being decoded.
От | Ashutosh Bapat |
---|---|
Тема | Re: Avoid distributing new catalog snapshot again for the transaction being decoded. |
Дата | |
Msg-id | CAExHW5tadBo0ba2nD1b54GirFwXU_dH-Q2fseQmoVQ45EwKcwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Avoid distributing new catalog snapshot again for the transaction being decoded. ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Avoid distributing new catalog snapshot again for the transaction being decoded.
|
Список | pgsql-hackers |
Hi Hou, Thanks for the patch. With a simple condition, we can eliminate the need to queueing snapshot change in the current transaction and then applying it. Saves some memory and computation. This looks useful. When the queue snapshot change is processed in ReorderBufferProcessTXN(), we call SetupHistoricSnapshot(). But I didn't find a path through which SetupHistoricSnapshot() is called from SnapBuildCommitTxn(). Either I missed some code path or it's not needed. Can you please enlighten me? -- Best Wishes, Ashutosh Bapat On Fri, Nov 25, 2022 at 2:28 PM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote: > > Hi, > > When doing some other related work, I noticed that when decoding the COMMIT > record via SnapBuildCommitTxn()-> SnapBuildDistributeNewCatalogSnapshot() we > will add a new snapshot to all transactions including the one being decoded(just committed one). > > But since we've already done required modifications in the snapshot for the > current transaction being decoded(in SnapBuildCommitTxn()), so I think we can > avoid adding a snapshot for it again. > > Here is the patch to improve this. > Thoughts ? > > Best regards, > Hou zhijie >
В списке pgsql-hackers по дате отправления: