1997-04-27 06:03:50 +02:00
|
|
|
--
|
2000-01-06 07:41:55 +01:00
|
|
|
-- BTREE_INDEX
|
|
|
|
-- test retrieval of min/max keys for each index
|
1997-04-27 06:03:50 +02:00
|
|
|
--
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_i4_heap b
|
|
|
|
WHERE b.seqno < 1;
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_i4_heap b
|
|
|
|
WHERE b.seqno >= 9999;
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_i4_heap b
|
|
|
|
WHERE b.seqno = 4500;
|
|
|
|
|
|
|
|
SELECT b.*
|
1998-04-26 06:12:15 +02:00
|
|
|
FROM bt_name_heap b
|
|
|
|
WHERE b.seqno < '1'::name;
|
1997-04-27 06:03:50 +02:00
|
|
|
|
|
|
|
SELECT b.*
|
1998-04-26 06:12:15 +02:00
|
|
|
FROM bt_name_heap b
|
|
|
|
WHERE b.seqno >= '9999'::name;
|
1997-04-27 06:03:50 +02:00
|
|
|
|
|
|
|
SELECT b.*
|
1998-04-26 06:12:15 +02:00
|
|
|
FROM bt_name_heap b
|
|
|
|
WHERE b.seqno = '4500'::name;
|
1997-04-27 06:03:50 +02:00
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_txt_heap b
|
|
|
|
WHERE b.seqno < '1'::text;
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_txt_heap b
|
|
|
|
WHERE b.seqno >= '9999'::text;
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_txt_heap b
|
|
|
|
WHERE b.seqno = '4500'::text;
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_f8_heap b
|
|
|
|
WHERE b.seqno < '1'::float8;
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_f8_heap b
|
|
|
|
WHERE b.seqno >= '9999'::float8;
|
|
|
|
|
|
|
|
SELECT b.*
|
|
|
|
FROM bt_f8_heap b
|
|
|
|
WHERE b.seqno = '4500'::float8;
|
|
|
|
|
2008-11-20 20:52:54 +01:00
|
|
|
--
|
|
|
|
-- Check correct optimization of LIKE (special index operator support)
|
|
|
|
-- for both indexscan and bitmapscan cases
|
|
|
|
--
|
|
|
|
|
|
|
|
set enable_seqscan to false;
|
|
|
|
set enable_indexscan to true;
|
|
|
|
set enable_bitmapscan to false;
|
2019-02-12 03:26:08 +01:00
|
|
|
explain (costs off)
|
2008-11-20 20:52:54 +01:00
|
|
|
select proname from pg_proc where proname like E'RI\\_FKey%del' order by 1;
|
2019-02-12 03:26:08 +01:00
|
|
|
select proname from pg_proc where proname like E'RI\\_FKey%del' order by 1;
|
|
|
|
explain (costs off)
|
|
|
|
select proname from pg_proc where proname ilike '00%foo' order by 1;
|
|
|
|
select proname from pg_proc where proname ilike '00%foo' order by 1;
|
|
|
|
explain (costs off)
|
|
|
|
select proname from pg_proc where proname ilike 'ri%foo' order by 1;
|
2008-11-20 20:52:54 +01:00
|
|
|
|
|
|
|
set enable_indexscan to false;
|
|
|
|
set enable_bitmapscan to true;
|
2019-02-12 03:26:08 +01:00
|
|
|
explain (costs off)
|
|
|
|
select proname from pg_proc where proname like E'RI\\_FKey%del' order by 1;
|
2008-11-20 20:52:54 +01:00
|
|
|
select proname from pg_proc where proname like E'RI\\_FKey%del' order by 1;
|
2019-02-12 03:26:08 +01:00
|
|
|
explain (costs off)
|
|
|
|
select proname from pg_proc where proname ilike '00%foo' order by 1;
|
|
|
|
select proname from pg_proc where proname ilike '00%foo' order by 1;
|
|
|
|
explain (costs off)
|
|
|
|
select proname from pg_proc where proname ilike 'ri%foo' order by 1;
|
|
|
|
|
|
|
|
reset enable_seqscan;
|
|
|
|
reset enable_indexscan;
|
|
|
|
reset enable_bitmapscan;
|
2014-11-19 18:24:58 +01:00
|
|
|
|
|
|
|
--
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-20 18:04:01 +01:00
|
|
|
-- Test B-tree fast path (cache rightmost leaf page) optimization.
|
2014-11-19 18:24:58 +01:00
|
|
|
--
|
|
|
|
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-20 18:04:01 +01:00
|
|
|
-- 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.)
|
2014-11-19 18:24:58 +01:00
|
|
|
--
|
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com
2019-03-20 18:04:01 +01:00
|
|
|
-- The text column must be the leading column in the index, since suffix
|
|
|
|
-- truncation would otherwise truncate tuples on internal pages, leaving us
|
|
|
|
-- with a short tree.
|
|
|
|
create table btree_tall_tbl(id int4, t text);
|
|
|
|
alter table btree_tall_tbl alter COLUMN t set storage plain;
|
|
|
|
create index btree_tall_idx on btree_tall_tbl (t, id) with (fillfactor = 10);
|
|
|
|
insert into btree_tall_tbl select g, repeat('x', 250)
|
|
|
|
from generate_series(1, 130) g;
|
Skip full index scan during cleanup of B-tree indexes when possible
Vacuum of index consists from two stages: multiple (zero of more) ambulkdelete
calls and one amvacuumcleanup call. When workload on particular table
is append-only, then autovacuum isn't intended to touch this table. However,
user may run vacuum manually in order to fill visibility map and get benefits
of index-only scans. Then ambulkdelete wouldn't be called for indexes
of such table (because no heap tuples were deleted), only amvacuumcleanup would
be called In this case, amvacuumcleanup would perform full index scan for
two objectives: put recyclable pages into free space map and update index
statistics.
This patch allows btvacuumclanup to skip full index scan when two conditions
are satisfied: no pages are going to be put into free space map and index
statistics isn't stalled. In order to check first condition, we store
oldest btpo_xact in the meta-page. When it's precedes RecentGlobalXmin, then
there are some recyclable pages. In order to check second condition we store
number of heap tuples observed during previous full index scan by cleanup.
If fraction of newly inserted tuples is less than
vacuum_cleanup_index_scale_factor, then statistics isn't considered to be
stalled. vacuum_cleanup_index_scale_factor can be defined as both reloption and GUC (default).
This patch bumps B-tree meta-page version. Upgrade of meta-page is performed
"on the fly": during VACUUM meta-page is rewritten with new version. No special
handling in pg_upgrade is required.
Author: Masahiko Sawada, Alexander Korotkov
Review by: Peter Geoghegan, Kyotaro Horiguchi, Alexander Korotkov, Yura Sokolov
Discussion: https://www.postgresql.org/message-id/flat/CAD21AoAX+d2oD_nrd9O2YkpzHaFr=uQeGr9s1rKC3O4ENc568g@mail.gmail.com
2018-04-04 18:29:00 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- Test vacuum_cleanup_index_scale_factor
|
|
|
|
--
|
|
|
|
|
|
|
|
-- Simple create
|
|
|
|
create table btree_test(a int);
|
|
|
|
create index btree_idx1 on btree_test(a) with (vacuum_cleanup_index_scale_factor = 40.0);
|
|
|
|
select reloptions from pg_class WHERE oid = 'btree_idx1'::regclass;
|
|
|
|
|
|
|
|
-- Fail while setting improper values
|
|
|
|
create index btree_idx_err on btree_test(a) with (vacuum_cleanup_index_scale_factor = -10.0);
|
|
|
|
create index btree_idx_err on btree_test(a) with (vacuum_cleanup_index_scale_factor = 100.0);
|
|
|
|
create index btree_idx_err on btree_test(a) with (vacuum_cleanup_index_scale_factor = 'string');
|
|
|
|
create index btree_idx_err on btree_test(a) with (vacuum_cleanup_index_scale_factor = true);
|
|
|
|
|
|
|
|
-- Simple ALTER INDEX
|
|
|
|
alter index btree_idx1 set (vacuum_cleanup_index_scale_factor = 70.0);
|
|
|
|
select reloptions from pg_class WHERE oid = 'btree_idx1'::regclass;
|
Split up a couple of long-running regression test scripts.
The point of this change is to increase the potential for parallelism
while running the core regression tests. Most people these days are
using parallel testing modes on multi-core machines, so we might as
well try a bit harder to keep multiple cores busy. Hence, a test that
runs much longer than others in its parallel group is a candidate to
be sub-divided.
In this patch, create_index.sql and join.sql are split up.
I haven't changed the content of the tests in any way, just
moved them.
I moved create_index.sql's SP-GiST-related tests into a new script
create_index_spgist, and moved its btree multilevel page deletion test
over to the existing script btree_index. (btree_index is a more natural
home for that test, and it's shorter than others in its parallel group,
so this doesn't hurt total runtime of that group.) There might be
room for more aggressive splitting of create_index, but this is enough
to improve matters considerably.
Likewise, I moved join.sql's "exercises for the hash join code" into
a new file join_hash. Those exercises contributed three-quarters of
the script's runtime. Which might well be excessive ... but for the
moment, I'm satisfied with shoving them into a different parallel
group, where they can share runtime with the roughly-equally-lengthy
gist test.
(Note for anybody following along at home: there are interesting
interactions between the runtimes of create_index and anything running
in parallel with it, because the tests of CREATE INDEX CONCURRENTLY
in that file will repeatedly block waiting for concurrent transactions
to commit. As committed in this patch, create_index and
create_index_spgist have roughly equal runtimes, but that's mostly an
artifact of forced synchronization of the CONCURRENTLY tests; when run
serially, create_index is much faster. A followup patch will reduce
the runtime of create_index_spgist and thereby also create_index.)
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us
2019-04-11 22:15:54 +02:00
|
|
|
|
|
|
|
--
|
|
|
|
-- Test for multilevel page deletion
|
|
|
|
--
|
|
|
|
CREATE TABLE delete_test_table (a bigint, b bigint, c bigint, d bigint);
|
|
|
|
INSERT INTO delete_test_table SELECT i, 1, 2, 3 FROM generate_series(1,80000) i;
|
|
|
|
ALTER TABLE delete_test_table ADD PRIMARY KEY (a,b,c,d);
|
|
|
|
-- Delete most entries, and vacuum, deleting internal pages and creating "fast
|
|
|
|
-- root"
|
|
|
|
DELETE FROM delete_test_table WHERE a < 79990;
|
|
|
|
VACUUM delete_test_table;
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Test B-tree insertion with a metapage update (XLOG_BTREE_INSERT_META
|
|
|
|
-- WAL record type). This happens when a "fast root" page is split. This
|
|
|
|
-- also creates coverage for nbtree FSM page recycling.
|
|
|
|
--
|
|
|
|
-- The vacuum above should've turned the leaf page into a fast root. We just
|
|
|
|
-- need to insert some rows to cause the fast root page to split.
|
|
|
|
INSERT INTO delete_test_table SELECT i, 1, 2, 3 FROM generate_series(1,1000) i;
|