webui: query fingerprinting and changes to plan or execution.

[awoods187]

In #50255 we introduced vectorized execution into the webui. In the example, I noticed that within the same query fingerprint we can present yes, no, or numerator/demoniator. For example, here is a 1/2:

This can be confusing to users because it doesn't explain why some queries are vectorized and some are not. Generalizing up a level, it won't be clear why the query fingerprint is sometimes faster and sometimes slower.

This has to do with the fact that we group queries based on fingerprinting. The same logical query (the same query fingerprint) could be run vectorized sometimes and sometimes not vectorized. For example this could be due to turning off the vectorized execution, lack of table statistics on the first run (this informs whether we use vectorized or not). This same methodology is also used to describe distributed execution. This begs the question, is it appropriate to group fingerprints if the execution changes?

What about if the plans change due to changing statistics?

Keeping the fingerprints grouped logically makes sense but it makes it hard to understand differences in query performance caused by changes in planning or execution. We should think about how to communicate this information.

Jira issue: CRDB-4138

[RaduBerinde]

I didn't know about this 1 of 2 feature. I tried to test things like this before but ran into #52788. Unfortunately, as of #52956, the server no longer returns separate instances of the stats for the same fingerprint depending on the vectorized status, so this likely doesn't work anymore on master. CC @dhartunian

[maryliag]

For the same fingerprint we now show a list of plans used, with their respective values of vectorize, full scan, and stats.
Closing this issue.