support high precision time in show processlist (I_S.processlist)

[inikep]

Summary:
The time information from 'show processlist' and in information_schema.processlist is at the granularity of a second
This diff provides an override (system variable) to display the time at the granularity of a micro-second (e.g, 0.001234)
The variable is session settable

Reference patch: b840ad76249

fbshipit-source-id: 7d58e50

TO DO: Please re-record mysql-test/t/all_persisted_variables.test with
let $total_persistent_vars=XXX + 1; (a new variable).

[facebook-github-bot]

@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[facebook-github-bot]

@inikep has updated the pull request. Re-import the pull request

[inikep]

This PR was updated:

• main.dd_is_compatibility_cs has been re-recorded

[facebook-github-bot]

@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[hermanlee]

Any particular reason for double vs. decimal as per the original diff?

[inikep]

I noticed some issues for 5.6:

1. INFORMATION_SCHEMA.PROCESSLIST "TIME" column defined as int(7)
   (i.e. "display width = 7" assumes numbers up to 9999999) was replaced
   with decimal(9,6) which can address only numbers from -999.999999 to
   999.999999
2. store_result_field_processlist() uses the double data type in
   5.6 to store time with
   protocol->store(my_timeval_to_double(&tm_delta), 6, &tmp_str);
   instead of protocol->store_decimal() that should be used for decimal(9,6)

I fixed these issues in my 8.0 port using:
'TIME' double NOT NULL DEFAULT '0' for INFORMATION_SCHEMA.PROCESSLIST

[hermanlee]

Should this also be a double to match the schema of processlist_fields_info? However, this still seems to be interpreted correctly from my testing.

[inikep]

We have 2 cases it this patch. The first case is SHOW PROCESSLIST which calls mysqld_list_processes(). It works fine because a result field type is send along with data:

field_list.push_back(new Item_return_int("Time", 6, MYSQL_TYPE_DOUBLE));
table->field[5]->store((double)time_delta / 1000000);

and

field_list.push_back(field = new Item_return_int("Time", 7, MYSQL_TYPE_LONG));
table->field[5]->store((long)(time_delta / 1000000), false);

The second case is SELECT * FROM information_schema.processlist that calls Fill_process_list::operator().
In this case we send a double or a long which is not correct according to a definition of the TIME filed of INFORMATION_SCHEMA.PROCESSLIST.

[facebook-github-bot]

@inikep has updated the pull request. Re-import the pull request

[inikep]

I updated the patch that TIME in INFORMATION_SCHEMA.PROCESSLIST is always double but with a different precision:

--- a/sql/sql_show.cc
+++ b/sql/sql_show.cc
@@ -2282,9 +2282,9 @@ class Fill_process_list : public Do_THD_Impl {
         my_timeval_to_micro_time(
             inspect_thd->query_start_timeval_trunc(DATETIME_MAX_DECIMALS));
     if (inspect_thd->variables.high_precision_processlist)
-      table->field[5]->store((double)time_delta / 1000000);
+      table->field[5]->store((double)time_delta / 1000000); // precision in microseconds
     else
-      table->field[5]->store((long)(time_delta / 1000000), false);
+      table->field[5]->store((double)(time_delta / 1000000)); // precision in seconds

[facebook-github-bot]

@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.