Re: Improve eviction algorithm in ReorderBuffer
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
Shubham Khanna <khannashubham1197@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-01T02:26:20Z
Lists: pgsql-hackers
Attachments
- v11-0002-Add-functions-to-binaryheap-for-efficient-key-re.patch (application/octet-stream) patch v11-0002
- v11-0001-Make-binaryheap-enlargeable.patch (application/octet-stream) patch v11-0001
- v11-0003-Improve-eviction-algorithm-in-Reorderbuffer-usin.patch (application/octet-stream) patch v11-0003
On Fri, Mar 29, 2024 at 7:37 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Mar 29, 2024 at 12:13 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Fri, Mar 29, 2024 at 2:09 PM vignesh C <vignesh21@gmail.com> wrote: > > > > > > On Tue, 26 Mar 2024 at 10:05, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > On Thu, Mar 14, 2024 at 12:02 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > > > > > > > > I've attached new version patches. > > > > > > > > Since the previous patch conflicts with the current HEAD, I've > > > > attached the rebased patches. > > > > > > Thanks for the updated patch. > > > One comment: > > > I felt we can mention the improvement where we update memory > > > accounting info at transaction level instead of per change level which > > > is done in ReorderBufferCleanupTXN, ReorderBufferTruncateTXN, and > > > ReorderBufferSerializeTXN also in the commit message: > > > > Agreed. > > > > I think the patch is in good shape. I'll push the patch with the > > suggestion next week, barring any objections. > > > > Few minor comments: > 1. > @@ -3636,6 +3801,8 @@ ReorderBufferCheckMemoryLimit(ReorderBuffer *rb) > Assert(txn->nentries_mem == 0); > } > > + ReorderBufferMaybeResetMaxHeap(rb); > + > > Can we write a comment about why this reset is required here? > Otherwise, the reason is not apparent. Yes, added. > > 2. > Although using max-heap to select the largest > + * transaction is effective when there are many transactions being decoded, > + * there is generally no need to use it as long as all transactions being > + * decoded are top-level transactions. Therefore, we use MaxConnections as the > + * threshold so we can prevent switching to the state unless we use > + * subtransactions. > + */ > +#define MAX_HEAP_TXN_COUNT_THRESHOLD MaxConnections > > Isn't using max-heap equally effective in finding the largest > transaction whether there are top-level or top-level plus > subtransactions? This comment indicates it is only effective when > there are subtransactions. You're right. Updated the comment. I've attached the updated patches. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
Commits
-
Revert indexed and enlargable binary heap implementation.
- 810f64a01567 17.0 landed
-
Replace binaryheap + index with pairingheap in reorderbuffer.c
- efb8acc0d058 17.0 landed
-
Improve eviction algorithm in ReorderBuffer using max-heap for many subtransactions.
- 5bec1d6bc5e3 17.0 landed
-
Add functions to binaryheap for efficient key removal and update.
- b84050864415 17.0 landed
-
Make binaryheap enlargeable.
- bcb14f4abca0 17.0 landed