Commit 17d6a8fb authored by Tom Lane's avatar Tom Lane

Improve stability of recently-added regression test case.

Commit b5febc1d added a contrib/btree_gist test case that has been
observed to fail in the buildfarm as a result of background auto-analyze
updating stats and changing the selected plan.  Forestall that by
forcibly analyzing in foreground, instead.  The new plan choice is
just as good for our purposes, since we really only care that an
index-only plan does not get selected.

Back-patch to 9.5, like the previous patch.

Discussion: https://postgr.es/m/14643.1539629304@sss.pgh.pa.us
parent 3dfef0c5
...@@ -64,18 +64,16 @@ SELECT count(*) FROM inettmp WHERE a > '89.225.196.191'::inet; ...@@ -64,18 +64,16 @@ SELECT count(*) FROM inettmp WHERE a > '89.225.196.191'::inet;
386 386
(1 row) (1 row)
VACUUM inettmp; VACUUM ANALYZE inettmp;
-- gist_inet_ops lacks a fetch function, so this should not be index-only scan -- gist_inet_ops lacks a fetch function, so this should not be index-only scan
EXPLAIN (COSTS OFF) EXPLAIN (COSTS OFF)
SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet;
QUERY PLAN QUERY PLAN
-------------------------------------------------------- --------------------------------------------------
Aggregate Aggregate
-> Bitmap Heap Scan on inettmp -> Index Scan using inetidx on inettmp
Recheck Cond: (a = '89.225.196.191'::inet) Index Cond: (a = '89.225.196.191'::inet)
-> Bitmap Index Scan on inetidx (3 rows)
Index Cond: (a = '89.225.196.191'::inet)
(5 rows)
SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet;
count count
...@@ -88,14 +86,12 @@ CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops); ...@@ -88,14 +86,12 @@ CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops);
-- likewise here (checks for core planner bug) -- likewise here (checks for core planner bug)
EXPLAIN (COSTS OFF) EXPLAIN (COSTS OFF)
SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet;
QUERY PLAN QUERY PLAN
-------------------------------------------------------- ----------------------------------------------------
Aggregate Aggregate
-> Bitmap Heap Scan on inettmp -> Index Scan using inettmp_a_a1_idx on inettmp
Recheck Cond: (a = '89.225.196.191'::inet) Index Cond: (a = '89.225.196.191'::inet)
-> Bitmap Index Scan on inettmp_a_a1_idx (3 rows)
Index Cond: (a = '89.225.196.191'::inet)
(5 rows)
SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet;
count count
......
...@@ -30,7 +30,7 @@ SELECT count(*) FROM inettmp WHERE a >= '89.225.196.191'::inet; ...@@ -30,7 +30,7 @@ SELECT count(*) FROM inettmp WHERE a >= '89.225.196.191'::inet;
SELECT count(*) FROM inettmp WHERE a > '89.225.196.191'::inet; SELECT count(*) FROM inettmp WHERE a > '89.225.196.191'::inet;
VACUUM inettmp; VACUUM ANALYZE inettmp;
-- gist_inet_ops lacks a fetch function, so this should not be index-only scan -- gist_inet_ops lacks a fetch function, so this should not be index-only scan
EXPLAIN (COSTS OFF) EXPLAIN (COSTS OFF)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment