postgres.git / summary / log / commit / refs

commit    6d2c760b059e4f16e2176fcfea6068d58cc3bf30
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Tue Oct 16 16:01:19 2018 +0000
First released in: 12.0, 9.5.15, 9.6.11, 10.6, 11.1

    Improve stability of recently-added regression test case.
    
    Commit b5febc1d1 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


contrib/btree_gist/expected/inet.out | 26 +++++++++++--------------- contrib/btree_gist/sql/inet.sql | 2 +- 2 files changed, 12 insertions(+), 16 deletions(-) diff --git a/contrib/btree_gist/expected/inet.out b/contrib/btree_gist/expected/inet.out index 905f55d740b..c323d903da4 100644 --- a/contrib/btree_gist/expected/inet.out +++ b/contrib/btree_gist/expected/inet.out @@ -64,18 +64,16 @@ SELECT count(*) FROM inettmp WHERE a > '89.225.196.191'::inet; 386 (1 row) -VACUUM inettmp; +VACUUM ANALYZE inettmp; -- gist_inet_ops lacks a fetch function, so this should not be index-only scan EXPLAIN (COSTS OFF) SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; - QUERY PLAN --------------------------------------------------------- + QUERY PLAN +-------------------------------------------------- Aggregate - -> Bitmap Heap Scan on inettmp - Recheck Cond: (a = '89.225.196.191'::inet) - -> Bitmap Index Scan on inetidx - Index Cond: (a = '89.225.196.191'::inet) -(5 rows) + -> Index Scan using inetidx on inettmp + Index Cond: (a = '89.225.196.191'::inet) +(3 rows) SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; count @@ -88,14 +86,12 @@ CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops); -- likewise here (checks for core planner bug) EXPLAIN (COSTS OFF) SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; - QUERY PLAN --------------------------------------------------------- + QUERY PLAN +---------------------------------------------------- Aggregate - -> Bitmap Heap Scan on inettmp - Recheck Cond: (a = '89.225.196.191'::inet) - -> Bitmap Index Scan on inettmp_a_a1_idx - Index Cond: (a = '89.225.196.191'::inet) -(5 rows) + -> Index Scan using inettmp_a_a1_idx on inettmp + Index Cond: (a = '89.225.196.191'::inet) +(3 rows) SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet; count diff --git a/contrib/btree_gist/sql/inet.sql b/contrib/btree_gist/sql/inet.sql index 08952f2c449..4b8d354b00e 100644 --- a/contrib/btree_gist/sql/inet.sql +++ b/contrib/btree_gist/sql/inet.sql @@ -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; -VACUUM inettmp; +VACUUM ANALYZE inettmp; -- gist_inet_ops lacks a fetch function, so this should not be index-only scan EXPLAIN (COSTS OFF) [parent: d11268237378]