aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistsplit.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-05-21 12:23:16 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2019-05-21 12:23:21 -0400
commitf03a9ca4366d064d89b7cf7ed75d4e43f2ed0667 (patch)
treec54f003d01691aa36351a5468998d752a19afe3a /src/backend/access/gist/gistsplit.c
parent1171d7d58545f26a402f76a05936d572bf29d53b (diff)
downloadpostgresql-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