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

Commit4b25f5d

Browse files
Revise BTP_HAS_GARBAGE nbtree VACUUM comments.
_bt_delitems_vacuum() comments claimed that it isn't worth another scanof the page to avoid falsely unsetting the BTP_HAS_GARBAGE page flaghint (this happens to be the same wording that was removed from_bt_delitems_delete() by my recent commitfe97c61). The comments madelittle sense, though. The issue can't have much to do with performing asecond scan of the target leaf page, since an LP_DEAD test could easilybe performed in the first scan of the page anyway (the scan that takesplace in btvacuumpage() caller).Revise the explanation. It makes much more sense to frame this as anissue about recovery conflicts. _bt_delitems_vacuum() cannot easilygenerate an XID cutoff in the same way that _bt_delitems_delete() isdesigned to.Falsely unsetting the page flag is not ideal, and is likely to happenmore often than was supposed by the original comments. Explain why itusually isn't a problem in practice. There may be an argument for_bt_delitems_vacuum() not clearing the BTP_HAS_GARBAGE bit, removing thequestion of it being falsely unset by VACUUM (there may even be anargument for not using a page level hint at all). This can be revisitedlater.
1 parent823e739 commit4b25f5d

File tree

1 file changed

+10
-3
lines changed

1 file changed

+10
-3
lines changed

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

Lines changed: 10 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1001,9 +1001,16 @@ _bt_delitems_vacuum(Relation rel, Buffer buf,
10011001
/*
10021002
* Mark the page as not containing any LP_DEAD items. This is not
10031003
* certainly true (there might be some that have recently been marked, but
1004-
* weren't included in our target-item list), but it will almost always be
1005-
* true and it doesn't seem worth an additional page scan to check it.
1006-
* Remember that BTP_HAS_GARBAGE is only a hint anyway.
1004+
* weren't targeted by VACUUM's heap scan), but it will be true often
1005+
* enough. VACUUM does not delete items purely because they have their
1006+
* LP_DEAD bit set, since doing so would necessitate explicitly logging a
1007+
* latestRemovedXid cutoff (this is how _bt_delitems_delete works).
1008+
*
1009+
* The consequences of falsely unsetting BTP_HAS_GARBAGE should be fairly
1010+
* limited, since we never falsely unset an LP_DEAD bit. Workloads that
1011+
* are particularly dependent on LP_DEAD bits being set quickly will
1012+
* usually manage to set the BTP_HAS_GARBAGE flag before the page fills up
1013+
* again anyway.
10071014
*/
10081015
opaque->btpo_flags &= ~BTP_HAS_GARBAGE;
10091016

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp