I wrote:
> Is there anything we can do to cut the runtime of the TAP test to
> the point where running it by default wouldn't be so painful?
As an experiment, I tried simply cutting the size of the test table 10X:
diff --git a/contrib/bloom/t/001_wal.pl b/contrib/bloom/t/001_wal.pl
index 1b319c9..566abf9 100644
--- a/contrib/bloom/t/001_wal.pl
+++ b/contrib/bloom/t/001_wal.pl
@@ -57,7 +57,7 @@ $node_standby->start;$node_master->safe_psql("postgres", "CREATE EXTENSION
bloom;");$node_master->safe_psql("postgres","CREATE TABLE tst (i int4, t text);");$node_master->safe_psql("postgres",
-"INSERT INTO tst SELECT i%10, substr(md5(i::text), 1, 1) FROM generate_series(1,100000) i;"
+"INSERT INTO tst SELECT i%10, substr(md5(i::text), 1, 1) FROM generate_series(1,10000)
i;");$node_master->safe_psql("postgres", "CREATE INDEX bloomidx ON tst USING bloom (i, t) WITH (col1 = 3);");
@@ -72,7 +72,7 @@ for my $i (1 .. 10) test_index_replay("delete $i"); $node_master->safe_psql("postgres", "VACUUM
tst;"); test_index_replay("vacuum $i");
- my ($start, $end) = (100001 + ($i - 1) * 10000, 100000 + $i * 10000);
+ my ($start, $end) = (10001 + ($i - 1) * 1000, 10000 + $i * 1000); $node_master->safe_psql("postgres","INSERT
INTOtst SELECT i%10, substr(md5(i::text), 1, 1) FROM generate_series($start,$end) i;" );
This about halved the runtime of the TAP test, and it changed the coverage
footprint not at all according to lcov. (Said coverage is only marginally
better than what we get without running the bloom TAP test, AFAICT.)
It seems like some effort could be put into both shortening this test
and improving the amount of code it exercises.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers