From f68faf4c7530e39e626b0aa3e4a36376e122fce7 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Fri, 5 Aug 2022 14:25:49 -0700 Subject: [PATCH] Fix comments about deduplication updating page. nbtree deduplication passes add tuples from the original/target page to a temp page, merging as necessary. The temp page is copied back to the target permanent page in the critical section. This is similar to the approach taken by nbtree page splits. Adjust comments that referred to updating the original page in-place as tuples were merged. These were left over from earlier versions of the deduplication patch that didn't yet use a temp page. --- src/backend/access/nbtree/nbtdedup.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/backend/access/nbtree/nbtdedup.c b/src/backend/access/nbtree/nbtdedup.c index 9e15ae57586..93a025b0a95 100644 --- a/src/backend/access/nbtree/nbtdedup.c +++ b/src/backend/access/nbtree/nbtdedup.c @@ -166,8 +166,8 @@ _bt_dedup_pass(Relation rel, Buffer buf, Relation heapRel, IndexTuple newitem, * maxpostingsize). * * If state contains pending posting list with more than one item, - * form new posting tuple, and actually update the page. Else - * reset the state and move on without modifying the page. + * form new posting tuple and add it to our temp page (newpage). + * Else add pending interval's base tuple to the temp page as-is. */ pagesaving += _bt_dedup_finish_pending(newpage, state); @@ -184,7 +184,8 @@ _bt_dedup_pass(Relation rel, Buffer buf, Relation heapRel, IndexTuple newitem, * stop merging together tuples altogether. The few tuples * that remain at the end of the page won't be merged together * at all (at least not until after a future page split takes - * place). + * place, when this page's newly allocated right sibling page + * gets its first deduplication pass). */ if (state->nmaxitems == 5) _bt_singleval_fillfactor(page, state, newitemsz);