Attached patch adjusts BRIN regression tests to make a non-obvious dependency on tuple order explicit. Currently, an index-only scan plan is used by the query that I've adjusted. I'd rather be sure that that continues.
This was spotted while running the regression tests with the Postgres default B-Tree fillfactor significantly reduced. There was only one other failure, but that one was really obvious; in general I wouldn't bother with "fixing" such things. This, however, seems problematic, because insertion order matters for the purposes of the test. It's perhaps implied that the test consistently relies on the stable order of things within the tenk1 table, but it isn't actually so. -- Peter Geoghegan
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out index 2be4b7c..6a0f207 100644 --- a/src/test/regress/expected/brin.out +++ b/src/test/regress/expected/brin.out @@ -61,7 +61,7 @@ INSERT INTO brintest (inetcol, cidrcol, int4rangecol) SELECT inet 'fe80::6e40:8ff:fea9:8c46' + tenthous, cidr 'fe80::6e40:8ff:fea9:8c46' + tenthous, 'empty'::int4range -FROM tenk1 LIMIT 25; +FROM tenk1 ORDER BY tenthous LIMIT 25; CREATE INDEX brinidx ON brintest USING brin ( byteacol, charcol, diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql index f47ef04..23c712a 100644 --- a/src/test/regress/sql/brin.sql +++ b/src/test/regress/sql/brin.sql @@ -63,7 +63,7 @@ INSERT INTO brintest (inetcol, cidrcol, int4rangecol) SELECT inet 'fe80::6e40:8ff:fea9:8c46' + tenthous, cidr 'fe80::6e40:8ff:fea9:8c46' + tenthous, 'empty'::int4range -FROM tenk1 LIMIT 25; +FROM tenk1 ORDER BY tenthous LIMIT 25; CREATE INDEX brinidx ON brintest USING brin ( byteacol,
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
