On Thu, 21 Mar 2024 at 12:36, Tom Lane <t...@sss.pgh.pa.us> wrote:
> So yeah, if we could have log_autovacuum_min_duration = 0 perhaps
> that would yield a clue.
FWIW, I agree with your earlier statement about it looking very much
like auto-vacuum has run on that table, but equally, if something like
the pg_index record was damaged we could get the same plan change.
We could also do something like the attached just in case we're
barking up the wrong tree.
David
diff --git a/src/test/regress/expected/partition_prune.out
b/src/test/regress/expected/partition_prune.out
index 7ca98397ae..f6950e160d 100644
--- a/src/test/regress/expected/partition_prune.out
+++ b/src/test/regress/expected/partition_prune.out
@@ -2449,6 +2449,37 @@ create index ab_a3_b3_a_idx on ab_a3_b3 (a);
set enable_hashjoin = 0;
set enable_mergejoin = 0;
set enable_memoize = 0;
+-- Temporarily install some debugging to investigate plan instability.
+select
c.relname,c.relpages,c.reltuples,i.indisvalid,s.autovacuum_count,s.autoanalyze_count
+from pg_class c
+left join pg_stat_all_tables s on c.oid = s.relid
+left join pg_index i on c.oid = i.indexrelid
+where c.relname like 'ab\_%' order by c.relname;
+ relname | relpages | reltuples | indisvalid | autovacuum_count |
autoanalyze_count
+----------------+----------+-----------+------------+------------------+-------------------
+ ab_a1 | 0 | -1 | | 0 |
0
+ ab_a1_b1 | 0 | -1 | | 0 |
0
+ ab_a1_b1_a_idx | 1 | 0 | t | |
+ ab_a1_b2 | 0 | -1 | | 0 |
0
+ ab_a1_b2_a_idx | 1 | 0 | t | |
+ ab_a1_b3 | 0 | -1 | | 0 |
0
+ ab_a1_b3_a_idx | 1 | 0 | t | |
+ ab_a2 | 0 | -1 | | 0 |
0
+ ab_a2_b1 | 0 | -1 | | 0 |
0
+ ab_a2_b1_a_idx | 1 | 0 | t | |
+ ab_a2_b2 | 0 | -1 | | 0 |
0
+ ab_a2_b2_a_idx | 1 | 0 | t | |
+ ab_a2_b3 | 0 | -1 | | 0 |
0
+ ab_a2_b3_a_idx | 1 | 0 | t | |
+ ab_a3 | 0 | -1 | | 0 |
0
+ ab_a3_b1 | 0 | -1 | | 0 |
0
+ ab_a3_b1_a_idx | 1 | 0 | t | |
+ ab_a3_b2 | 0 | -1 | | 0 |
0
+ ab_a3_b2_a_idx | 1 | 0 | t | |
+ ab_a3_b3 | 0 | -1 | | 0 |
0
+ ab_a3_b3_a_idx | 1 | 0 | t | |
+(21 rows)
+
select explain_parallel_append('select avg(ab.a) from ab inner join lprt_a a
on ab.a = a.a where a.a in(0, 0, 1)');
explain_parallel_append
--------------------------------------------------------------------------------------------------------
diff --git a/src/test/regress/sql/partition_prune.sql
b/src/test/regress/sql/partition_prune.sql
index a09b27d820..3ce90f2d89 100644
--- a/src/test/regress/sql/partition_prune.sql
+++ b/src/test/regress/sql/partition_prune.sql
@@ -607,6 +607,13 @@ set enable_hashjoin = 0;
set enable_mergejoin = 0;
set enable_memoize = 0;
+-- Temporarily install some debugging to investigate plan instability.
+select
c.relname,c.relpages,c.reltuples,i.indisvalid,s.autovacuum_count,s.autoanalyze_count
+from pg_class c
+left join pg_stat_all_tables s on c.oid = s.relid
+left join pg_index i on c.oid = i.indexrelid
+where c.relname like 'ab\_%' order by c.relname;
+
select explain_parallel_append('select avg(ab.a) from ab inner join lprt_a a
on ab.a = a.a where a.a in(0, 0, 1)');
-- Ensure the same partitions are pruned when we make the nested loop
