Suppress invalid column errors in vtexplain

[tycol7]

Description

This PR suppresses unwanted invalid column errors in vtexplain.

After changing the way we encode queries, vtexplain started showing these errors on routine executions:

vtexplain_vttablet.go:838] vtexplain: invalid column .column_name, tableColumnMap +map[:map[]]

This repeated error causes vtexplain to significantly slow down. We get this error whenever the following query is executed:

SELECT COLUMN_NAME as column_name
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = database() AND TABLE_NAME = 'table_name_being_vtexplained'
ORDER BY ORDINAL_POSITION

Previously, the above query evaluated to:

&{[name:"column_type" type:VARCHAR] %!s(uint64=0) %!s(uint64=0) [[VARCHAR("id")] [VARCHAR("next_id")] [VARCHAR("cache")]]  %!s(uint16=0) }

After the change, the query evaluates to:

&{[name:"column_name"] %!s(uint64=0) %!s(uint64=0) [[NULL]]  %!s(uint16=0) }

and importantly, is now classified as a SELECT:

vitess/go/vt/vtexplain/vtexplain_vttablet.go

Lines 577 to 583 in 54c6dfc

	switch sqlparser.Preview(query) {
	case sqlparser.StmtSelect:
	var err error
	result, err = t.handleSelect(query)
	if err != nil {
	return err
	}

handleSelect kicks off a series of steps, including inferring the column type, which is null after the change.

This PR adds logic such that if we are in the special case of a null column type and the column name is column_name, do not log an error. Not logging an error reduces vtexplain's runtime by several factors.

This is a bug fix, and I think it should be backported.

Related Issue(s)

Fixes #15242

Checklist

• "Backport to:" labels have been added if this change should be back-ported to release branches
• If this change is to be back-ported to previous releases, a justification is included in the PR description
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on CI?
• Documentation was added or is not required

Deployment Notes

N/A

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (de3c9c5) 67.46% compared to head (926b944) 67.46%.
Report is 7 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #15272   +/-   ##
=======================================
  Coverage   67.46%   67.46%           
=======================================
  Files        1560     1561    +1     
  Lines      193186   193193    +7     
=======================================
+ Hits       130333   130339    +6     
- Misses      62853    62854    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dbussink]

Previously, the above query evaluated to:

&{[name:"column_type" type:VARCHAR] %!s(uint64=0) %!s(uint64=0) [[VARCHAR("id")] [VARCHAR("next_id")] [VARCHAR("cache")]]  %!s(uint16=0) }

After the change, the query evaluates to:

&{[name:"column_name"] %!s(uint64=0) %!s(uint64=0) [[NULL]]  %!s(uint16=0) }

If this changed, that was probably not intentional and that is what we need to fix and not suppress the logging? Isn't something now broken then in vtexplain itself?

I feel like the actual underlying issue is not really understood well yet to know how this should be fixed?

[dbussink]

Alright, I found the actual cause of the invalid column .column_name bug. I'll open a PR for that.

[dbussink]

Closing in favor of the actual fix in #15275. The logging here was correct, we did have a real problem as I suspected and we need to fix that underlying problem.