From 739abf5195765914fad6f759f4b08e2a09a6006a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marko=20M=C3=A4kel=C3=A4?= Date: Sun, 7 Feb 2021 14:31:48 +0200 Subject: [PATCH] Make innodb_gis.rtree_purge run faster A locking SELECT from an InnoDB table is very slow especially in debug builds. Replacing some INSERT...SELECT should not reduce the test coverage, because the test will still do DELETE (which will acquire explicit record locks). --- mysql-test/suite/innodb_gis/t/rtree_purge.test | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mysql-test/suite/innodb_gis/t/rtree_purge.test b/mysql-test/suite/innodb_gis/t/rtree_purge.test index 42f00428b88..60ecbe2e53a 100644 --- a/mysql-test/suite/innodb_gis/t/rtree_purge.test +++ b/mysql-test/suite/innodb_gis/t/rtree_purge.test @@ -1,7 +1,7 @@ # This test case will test R-tree purge. --source include/innodb_page_size.inc -# Valgrind takes too much time on PB2 even in the --big-test runs. +--source include/have_sequence.inc --source include/not_valgrind.inc SET @saved_frequency = @@GLOBAL.innodb_purge_rseg_truncate_frequency; @@ -16,9 +16,7 @@ set @p=point(1,1); let $n=200; while ($n) { begin; -insert into t values(@p,@p),(@p,@p); -insert into t select @p,@p -from t a,t b,t c,t d,t e,t f,t g; +insert into t select @p,@p from seq_1_to_130; delete from t; commit; dec $n;