Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitdd94c28

Browse files
Fix "single value strategy" index deletion issue.
It is not appropriate for deduplication to apply single value strategywhen triggered by a bottom-up index deletion pass. This wastes cyclesbecause later bottom-up deletion passes will overinterpret olderduplicate tuples that deduplication actually just skipped over "bydesign". It also makes bottom-up deletion much less effective for lowcardinality indexes that happen to cross a meaningless "index has singlekey value per leaf page" threshold.To fix, slightly narrow the conditions under which deduplication'ssingle value strategy is considered. We already avoided the strategyfor a unique index, since our high level goal must just be to buy timefor VACUUM to run (not to buy space). We'll now also avoid it when wejust had a bottom-up pass that reported failure. The two cases sharethe same high level goal, and already overlapped significantly, so thisapproach is quite natural.Oversight in commitd168b66, which added bottom-up index deletion.Author: Peter Geoghegan <pg@bowt.ie>Discussion:https://postgr.es/m/CAH2-WznaOvM+Gyj-JQ0X=JxoMDxctDTYjiEuETdAGbF5EUc3MA@mail.gmail.comBackpatch: 14-, where bottom-up deletion was introduced.
1 parent1a9d802 commitdd94c28

File tree

3 files changed

+19
-21
lines changed

3 files changed

+19
-21
lines changed

‎src/backend/access/nbtree/nbtdedup.c

Lines changed: 17 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -34,14 +34,17 @@ static bool _bt_posting_valid(IndexTuple posting);
3434
*
3535
* The general approach taken here is to perform as much deduplication as
3636
* possible to free as much space as possible. Note, however, that "single
37-
* value" strategy is sometimes used for !checkingunique callers, in which
38-
* case deduplication will leave a few tuples untouched at the end of the
39-
* page. The general idea is to prepare the page for an anticipated page
40-
* split that uses nbtsplitloc.c's "single value" strategy to determine a
41-
* split point. (There is no reason to deduplicate items that will end up on
42-
* the right half of the page after the anticipated page split; better to
43-
* handle those if and when the anticipated right half page gets its own
44-
* deduplication pass, following further inserts of duplicates.)
37+
* value" strategy is used for !bottomupdedup callers when the page is full of
38+
* tuples of a single value. Deduplication passes that apply the strategy
39+
* will leave behind a few untouched tuples at the end of the page, preparing
40+
* the page for an anticipated page split that uses nbtsplitloc.c's own single
41+
* value strategy. Our high level goal is to delay merging the untouched
42+
* tuples until after the page splits.
43+
*
44+
* When a call to _bt_bottomupdel_pass() just took place (and failed), our
45+
* high level goal is to prevent a page split entirely by buying more time.
46+
* We still hope that a page split can be avoided altogether. That's why
47+
* single value strategy is not even considered for bottomupdedup callers.
4548
*
4649
* The page will have to be split if we cannot successfully free at least
4750
* newitemsz (we also need space for newitem's line pointer, which isn't
@@ -52,7 +55,7 @@ static bool _bt_posting_valid(IndexTuple posting);
5255
*/
5356
void
5457
_bt_dedup_pass(Relationrel,Bufferbuf,RelationheapRel,IndexTuplenewitem,
55-
Sizenewitemsz,boolcheckingunique)
58+
Sizenewitemsz,boolbottomupdedup)
5659
{
5760
OffsetNumberoffnum,
5861
minoff,
@@ -97,8 +100,11 @@ _bt_dedup_pass(Relation rel, Buffer buf, Relation heapRel, IndexTuple newitem,
97100
minoff=P_FIRSTDATAKEY(opaque);
98101
maxoff=PageGetMaxOffsetNumber(page);
99102

100-
/* Determine if "single value" strategy should be used */
101-
if (!checkingunique)
103+
/*
104+
* Consider applying "single value" strategy, though only if the page
105+
* seems likely to be split in the near future
106+
*/
107+
if (!bottomupdedup)
102108
singlevalstrat=_bt_do_singleval(rel,page,state,minoff,newitem);
103109

104110
/*
@@ -764,14 +770,6 @@ _bt_bottomupdel_finish_pending(Page page, BTDedupState state,
764770
* the first pass) won't spend many cycles on the large posting list tuples
765771
* left by previous passes. Each pass will find a large contiguous group of
766772
* smaller duplicate tuples to merge together at the end of the page.
767-
*
768-
* Note: We deliberately don't bother checking if the high key is a distinct
769-
* value (prior to the TID tiebreaker column) before proceeding, unlike
770-
* nbtsplitloc.c. Its single value strategy only gets applied on the
771-
* rightmost page of duplicates of the same value (other leaf pages full of
772-
* duplicates will get a simple 50:50 page split instead of splitting towards
773-
* the end of the page). There is little point in making the same distinction
774-
* here.
775773
*/
776774
staticbool
777775
_bt_do_singleval(Relationrel,Pagepage,BTDedupStatestate,

‎src/backend/access/nbtree/nbtinsert.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2748,7 +2748,7 @@ _bt_delete_or_dedup_one_page(Relation rel, Relation heapRel,
27482748
/* Perform deduplication pass (when enabled and index-is-allequalimage) */
27492749
if (BTGetDeduplicateItems(rel)&&itup_key->allequalimage)
27502750
_bt_dedup_pass(rel,buffer,heapRel,insertstate->itup,
2751-
insertstate->itemsz,checkingunique);
2751+
insertstate->itemsz,(indexUnchanged||uniquedup));
27522752
}
27532753

27542754
/*

‎src/include/access/nbtree.h

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1155,7 +1155,7 @@ extern void _bt_parallel_advance_array_keys(IndexScanDesc scan);
11551155
*/
11561156
externvoid_bt_dedup_pass(Relationrel,Bufferbuf,RelationheapRel,
11571157
IndexTuplenewitem,Sizenewitemsz,
1158-
boolcheckingunique);
1158+
boolbottomupdedup);
11591159
externbool_bt_bottomupdel_pass(Relationrel,Bufferbuf,RelationheapRel,
11601160
Sizenewitemsz);
11611161
externvoid_bt_dedup_start_pending(BTDedupStatestate,IndexTuplebase,

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp