ui,sql: add Vectorized info to statements page

[yuzefovich]

This commit adds a box to Statements page that displays whether the
vectorized execution engine is used.

Release note (admin ui change): Statements page now contains information
about which execution engine is used (vectorized or not).

[cockroach-teamcity]

This change is 

[awoods187]

Thanks for jumping on this! Do you have a screenshot of what this will look like?

[yuzefovich]

Yes, I do (of the relevant section). I made the screenshot yesterday but forgot to add it here. Let me know if you're interested in the shot of the whole screen.

[awoods187]

Thanks for sharing! What does 1 of 2 mean?

[yuzefovich]

It is the same as for Distributed execution: we represent that information as a "fraction", so 1 of 2 means that out of two times the query was executed, it ran once via the vectorized engine and once via the old engine. In edge cases we show the words: "no" if we have 0 out of any number of runs, and "yes" if the numerator of the "fraction" equals the denominator.

[awoods187]

Gotcha. I predict that it will be confusing to the user why the query fingerprint is sometimes run in vectorized and sometime not.

In fact, why would that be the case? Is this an indication that we shouldn't actually be grouping these two queries under the same fingerprint?

[yuzefovich]

I predict that it will be confusing to the user why the query fingerprint is sometimes run in vectorized and sometime not.

Yeah, it might be confusing, but we use the exactly same representation for "Distributed execution" (as well as for "Used cost-based optimizer" but this one is now always yes), so I think it is something for UI team to look at.

In fact, why would that be the case?

In my scenario I explicitly changed vectorize setting manually. The users will probably not be doing that, so they will see either "no" or "yes". There is, however, a scenario when the user might see "no vectorization" for short period of time (while table statistics haven't been collected) which switches to "used vectorization" (because we rely on statistics to make a decision whether to vectorize or not, and if stats are not present, we do not vectorize).

Is this an indication that we shouldn't actually be grouping these two queries under the same fingerprint?

I think the current grouping is reasonable, and I don't have a good feeling of what would be more preferable grouping criteria.

[awoods187]

Alright, I opened up #50284 to discuss this further--don't let that conversation impact this PR.

[koorosh]

LGTM (regarding UI changes)

[rohany]

stats related changes look fine

[rohany]

[nit]: this is too long for one line now

[rohany]

why don't we check here if the flow was vectorized or not? Why do we look at a setting

[yuzefovich]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @RaduBerinde and @rohany)

---

pkg/sql/app_stats.go, line 146 at r1 (raw file):

Previously, rohany (Rohan Yadav) wrote…

[nit]: this is too long for one line now

Done.

---

pkg/sql/distsql_running.go, line 267 at r1 (raw file):

Previously, rohany (Rohan Yadav) wrote…

why don't we check here if the flow was vectorized or not? Why do we look at a setting

Indeed, good point, fixed.

[yuzefovich]

TFTRs!

bors r+

[craig]

Build succeeded

• GitHub CI (Cockroach)