roachtest: fix tpchvec/perf in some cases#53911
roachtest: fix tpchvec/perf in some cases#53911craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
|
This change is |
asubiotto
left a comment
There was a problem hiding this comment.
I'm a bit confused. I'm not sure I understand how this log message helps determining whether EXPLAIN ANALYZE ran on the query. Is it part of cluster setup?
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @asubiotto)
yuzefovich
left a comment
There was a problem hiding this comment.
Before we run EXPLAIN ANALYZE, we perform the necessary cluster setup on all configs, so I want to make sure that the correct queries are executed during that setup. Confusingly, in the logs I did see a message about vectorize being set to off, but still only the vectorized stats were available.
Reviewable status:
|
To provide more context - the sequence is:
So printing the queries into the logs will show exactly what queries have been executed before running EXPLAIN ANALYZE. |
asubiotto
left a comment
There was a problem hiding this comment.
Have you tried inducing a failure locally? Does EXPLAIN ANALYZE get run in this case?
Reviewable status:
|
Forcing the collection of the bundle manually I still see that we correctly execute the cluster setup for vectorize=off case, yet the stats are collected as if vectorize=on is set. Digging into this. |
Previously, whenever a slowness threshold is exceeded, we would run EXPLAIN ANALYZE (DEBUG) on the query at fault using the same connection for all cluster setups. This would result in running the query only with vectorize=on which is not what we want. We will now be opening up new connections to the database after the cluster settings have been updated in order to get the correct behavior for each of the setups. Release note: None
|
Updated the PR to fix the problem with the wrong config being used during EXPLAIN ANALYZE (DEBUG) and confirmed manually that the bundles are as expected. RFAL. |
asubiotto
left a comment
There was a problem hiding this comment.
Reviewable status:
|
TFTR! bors r+ |
|
Build succeeded: |
Previously, whenever a slowness threshold is exceeded, we would run
EXPLAIN ANALYZE (DEBUG) on the query at fault using the same connection
for all cluster setups. This would result in running the query only with
vectorize=on which is not what we want. We will now be opening up new
connections to the database after the cluster settings have been updated
in order to get the correct behavior for each of the setups.
Informs: #53884.
Release note: None