*: create / drop extended stats by ALTER TABLE

[eurekaka]

What problem does this PR solve?

Change the extended statistics SQL interfaces according to https://docs.google.com/document/d/1rRIQ8ekoKJH8qeB-J15QRaycLys8_19GBnij7q_O7Vg/edit.

What is changed and how it works?

Use ALTER TABLE ... ADD / DROP STATISTICS syntax for create / drop extended statistics. Old syntax in #913 would be removed later once the new syntax support is finished.

Check List

Tests

• Unit test

Code changes

• Has exported function/method change
• Has exported variable/fields change

Side effects

• Breaking backward compatibility: the old syntax is not generally available now, so it should be fine to be removed.

Related changes

N/A

[eurekaka]

This would make statistics a reserved keyword, while in previous syntax implementation, it is just a TiDB keyword. If we don't do this, the newly added rule would have shift/reduce conflict with ColumnKeywordOpt, because statistics can be treated as a column name for ADD [COLUMN] statistics.

[kennytm]

Making statistics or stats a reserved keyword just to avoid having the "frankenstein" CREATE STATISTICS syntax (already used by T-SQL and PostgreSQL) is not a good trade-off imo.

[eurekaka]

@zz-jason @morgo what's your opinion?

[zz-jason]

For better syntax compatibility with MySQL, I think it's worthy.

[kennytm]

and what about TIDB_STATS / TIDB_STATISTICS 🤔

[morgo]

I agree with kennytm. stats / statistics is not a reserved word in the SQL standard, or in MySQL. It doesn't hurt usability too much to use TIDB_STATISTICS or OPTIMIZER_STATISTICS instead.

[eurekaka]

Alright, I replaced statistics with tidb_stats, shall we use admin reload statistics or admin reload tidb_stats then?

[morgo]

I like the consistency of admin reload tidb_stats, but not a strong opinion.

[zz-jason]

If we choose tidb_stats, lots of SQL grammar might need to be modified to keep consistency.

For example, some SQL syntaxes:

show stats_meta;
load stats;

Config:

stats-lease = "3s"

HTTP API:

http://$host:$port/stats/dump/$db/$table

And some tables:

stats_buckets
stats_feedback
stats_histograms
stats_meta
stats_top_n

keeping the name to be consistent helps users to easily remember these concepts. I prefer to use stats for drop and alter table statements.

[time-and-fate]

What about replacing TIDB_STATS with STATS_EXTENDED to keep consistency? @zz-jason

ALTER TABLE t ADD stats_extended s1 dependency(a,b);
ALTER TABLE t DROP stats_extended s1;
ADMIN RELOAD stats_extended;

or maybe a shorter STATS_EXT?

[kennytm]

LGTM

[winoros]

lgtm