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

Commit385d396

Browse files
committed
Split up a couple of long-running regression test scripts.
The point of this change is to increase the potential for parallelismwhile running the core regression tests. Most people these days areusing parallel testing modes on multi-core machines, so we might aswell try a bit harder to keep multiple cores busy. Hence, a test thatruns much longer than others in its parallel group is a candidate tobe 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, justmoved them.I moved create_index.sql's SP-GiST-related tests into a new scriptcreate_index_spgist, and moved its btree multilevel page deletion testover to the existing script btree_index. (btree_index is a more naturalhome 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 beroom for more aggressive splitting of create_index, but this is enoughto improve matters considerably.Likewise, I moved join.sql's "exercises for the hash join code" intoa new file join_hash. Those exercises contributed three-quarters ofthe script's runtime. Which might well be excessive ... but for themoment, I'm satisfied with shoving them into a different parallelgroup, where they can share runtime with the roughly-equally-lengthygist test.(Note for anybody following along at home: there are interestinginteractions between the runtimes of create_index and anything runningin parallel with it, because the tests of CREATE INDEX CONCURRENTLYin that file will repeatedly block waiting for concurrent transactionsto commit. As committed in this patch, create_index andcreate_index_spgist have roughly equal runtimes, but that's mostly anartifact of forced synchronization of the CONCURRENTLY tests; when runserially, create_index is much faster. A followup patch will reducethe runtime of create_index_spgist and thereby also create_index.)Discussion:https://postgr.es/m/735.1554935715@sss.pgh.pa.us
1 parent6726d8d commit385d396

13 files changed

+3353
-3319
lines changed

‎src/test/regress/expected/btree_index.out

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -244,3 +244,21 @@ select reloptions from pg_class WHERE oid = 'btree_idx1'::regclass;
244244
{vacuum_cleanup_index_scale_factor=70.0}
245245
(1 row)
246246

247+
--
248+
-- Test for multilevel page deletion
249+
--
250+
CREATE TABLE delete_test_table (a bigint, b bigint, c bigint, d bigint);
251+
INSERT INTO delete_test_table SELECT i, 1, 2, 3 FROM generate_series(1,80000) i;
252+
ALTER TABLE delete_test_table ADD PRIMARY KEY (a,b,c,d);
253+
-- Delete most entries, and vacuum, deleting internal pages and creating "fast
254+
-- root"
255+
DELETE FROM delete_test_table WHERE a < 79990;
256+
VACUUM delete_test_table;
257+
--
258+
-- Test B-tree insertion with a metapage update (XLOG_BTREE_INSERT_META
259+
-- WAL record type). This happens when a "fast root" page is split. This
260+
-- also creates coverage for nbtree FSM page recycling.
261+
--
262+
-- The vacuum above should've turned the leaf page into a fast root. We just
263+
-- need to insert some rows to cause the fast root page to split.
264+
INSERT INTO delete_test_table SELECT i, 1, 2, 3 FROM generate_series(1,1000) i;

0 commit comments

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