diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-05-21 12:23:16 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-05-21 12:23:21 -0400 |
commit | f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667 (patch) | |
tree | c54f003d01691aa36351a5468998d752a19afe3a /src/backend/access/gist/gistsplit.c | |
parent | 1171d7d58545f26a402f76a05936d572bf29d53b (diff) | |
download | postgresql-f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667.tar.gz postgresql-f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667.zip |
Insert temporary debugging output in regression tests.
We're seeing occasional instability in the plans generated for
parallel queries on the "a_star" table hierarchy. This suggests
that something is changing the planner's stats for those tables,
but that should not be happening within a regression test run.
To try to gather some information about what's happening, insert
additional queries to check the basic page/tuple counts for these
tables, as well as whether any vacuums or analyzes have happened
on them. (We expect that only the database-wide VACUUM in
sanity_check.sql will have touched them.)
I added the probes not only in select_parallel.sql itself, but
also in stats.sql, bearing in mind that the stats collector's
lag may prevent the initial query from reporting current truth.
If any extra vacuum/analyze has happened, the recheck in stats.sql
definitely ought to see it.
This commit can be reverted once we figure out what's going on.
Per suggestion from David Rowley, though I changed the queries around.
Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistsplit.c')
0 files changed, 0 insertions, 0 deletions