From 52b164c5a00095a34685e66bf64b009578b9cfda Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Tue, 28 Apr 2020 16:12:56 -0700 Subject: [PATCH] Add LP_DEAD deletion of a posting list tuple test. Make sure that we have test coverage of the posting list tuple path within _bt_xid_horizon(). Per off-list complaint from Andres Freund. --- src/test/regress/expected/btree_index.out | 13 ++++++++++--- src/test/regress/sql/btree_index.sql | 14 +++++++++++--- 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/src/test/regress/expected/btree_index.out b/src/test/regress/expected/btree_index.out index c0657020b0..cfd4338e36 100644 --- a/src/test/regress/expected/btree_index.out +++ b/src/test/regress/expected/btree_index.out @@ -284,14 +284,21 @@ BEGIN INSERT INTO dedup_unique_test_table SELECT 1; END LOOP; END$$; +-- Exercise the LP_DEAD-bit-set tuple deletion code with a posting list tuple. +-- The implementation prefers deleting existing items to merging any duplicate +-- tuples into a posting list, so we need an explicit test to make sure we get +-- coverage (note that this test also assumes BLCKSZ is 8192 or less): +DROP INDEX plain_unique; +DELETE FROM dedup_unique_test_table WHERE a = 1; +INSERT INTO dedup_unique_test_table SELECT i FROM generate_series(0,450) i; -- -- Test B-tree fast path (cache rightmost leaf page) optimization. -- -- First create a tree that's at least three levels deep (i.e. has one level -- between the root and leaf levels). The text inserted is long. It won't be --- compressed because we use plain storage in the table. Only a few index --- tuples fit on each internal page, allowing us to get a tall tree with few --- pages. (A tall tree is required to trigger caching.) +-- TOAST compressed because we use plain storage in the table. Only a few +-- index tuples fit on each internal page, allowing us to get a tall tree with +-- few pages. (A tall tree is required to trigger caching.) -- -- The text column must be the leading column in the index, since suffix -- truncation would otherwise truncate tuples on internal pages, leaving us diff --git a/src/test/regress/sql/btree_index.sql b/src/test/regress/sql/btree_index.sql index 4245cbb80c..96f53818ff 100644 --- a/src/test/regress/sql/btree_index.sql +++ b/src/test/regress/sql/btree_index.sql @@ -123,15 +123,23 @@ BEGIN END LOOP; END$$; +-- Exercise the LP_DEAD-bit-set tuple deletion code with a posting list tuple. +-- The implementation prefers deleting existing items to merging any duplicate +-- tuples into a posting list, so we need an explicit test to make sure we get +-- coverage (note that this test also assumes BLCKSZ is 8192 or less): +DROP INDEX plain_unique; +DELETE FROM dedup_unique_test_table WHERE a = 1; +INSERT INTO dedup_unique_test_table SELECT i FROM generate_series(0,450) i; + -- -- Test B-tree fast path (cache rightmost leaf page) optimization. -- -- First create a tree that's at least three levels deep (i.e. has one level -- between the root and leaf levels). The text inserted is long. It won't be --- compressed because we use plain storage in the table. Only a few index --- tuples fit on each internal page, allowing us to get a tall tree with few --- pages. (A tall tree is required to trigger caching.) +-- TOAST compressed because we use plain storage in the table. Only a few +-- index tuples fit on each internal page, allowing us to get a tall tree with +-- few pages. (A tall tree is required to trigger caching.) -- -- The text column must be the leading column in the index, since suffix -- truncation would otherwise truncate tuples on internal pages, leaving us