mirror of
https://github.com/postgres/postgres.git
synced 2025-10-22 14:32:25 +03:00
Fix "single value strategy" index deletion issue.
It is not appropriate for deduplication to apply single value strategy
when triggered by a bottom-up index deletion pass. This wastes cycles
because later bottom-up deletion passes will overinterpret older
duplicate tuples that deduplication actually just skipped over "by
design". It also makes bottom-up deletion much less effective for low
cardinality indexes that happen to cross a meaningless "index has single
key value per leaf page" threshold.
To fix, slightly narrow the conditions under which deduplication's
single value strategy is considered. We already avoided the strategy
for a unique index, since our high level goal must just be to buy time
for VACUUM to run (not to buy space). We'll now also avoid it when we
just had a bottom-up pass that reported failure. The two cases share
the same high level goal, and already overlapped significantly, so this
approach is quite natural.
Oversight in commit d168b666
, which added bottom-up index deletion.
Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-WznaOvM+Gyj-JQ0X=JxoMDxctDTYjiEuETdAGbF5EUc3MA@mail.gmail.com
Backpatch: 14-, where bottom-up deletion was introduced.
This commit is contained in:
@@ -1155,7 +1155,7 @@ extern void _bt_parallel_advance_array_keys(IndexScanDesc scan);
|
||||
*/
|
||||
extern void _bt_dedup_pass(Relation rel, Buffer buf, Relation heapRel,
|
||||
IndexTuple newitem, Size newitemsz,
|
||||
bool checkingunique);
|
||||
bool bottomupdedup);
|
||||
extern bool _bt_bottomupdel_pass(Relation rel, Buffer buf, Relation heapRel,
|
||||
Size newitemsz);
|
||||
extern void _bt_dedup_start_pending(BTDedupState state, IndexTuple base,
|
||||
|
Reference in New Issue
Block a user