fix 1:#818 Master slave synchronization - There will be too many tuples problem

Cause:
Tianmu::dbhandler::TianmuHandler::current_position This variable is not initialized. In some cases,
a large value may cause too many tuples problem.
Solution: Initialize the variable

fix 2:#819 Master slave synchronization - Primary key conflict problem

Solution: Modify the modification logic of master slave synchronization, so that the delete and update operations do not follow the primary key logic

Supplement

sql/sql_insert.cc
Fix the problem that the insert statement will not generate binlog in the delayed insert mode
storage/tianmu/handler/tianmu_handler.cpp
Fix the binlog error of the line format generated by the tianmu engine

[summary]
1 class member variable refactor：exproter directory;
2 class member variable refactor：loader directory;

[summary]

NULL-->nullptr
namespace "DBHandler"-->"handler"
class TianmuHandler-->ha_tianmu
sdb-->tianmu
functions in ha_my_tianmu.cpp all renamed with prefix "ha_my_tianmu_xxx"

 [summary]
 1.class member variable refactor：common directory;

class member variable refactor：handler directory

[summary]
1 class member variable refactor：compress directory;
2 class member variable refactor：types directory;

Eplain query Q4 lead to crash,because assert(join == NULL) in SELECT_LEX::optimize() function.
the root cause is that the new join is not released. we can use sl->cleanup(true) to release it

Cause:
When the date in MySQL is 0, the value is considered to be null. MySQL handles this problem. If you query the statement of isull,
you will convert isnull to=0. This problem is that the value with the date of 0 is inserted into the table.
The query and deletion results of the tianmu engine are not consistent.
The reason for the inconsistency is that the syntax parsing logic of the query and deletion of tianmu is not the same
Solution:
Unified query logic and modification logic for date format processing.
Keep the phenomenon of tianmu consistent with innodb.

fix(tianmu): feature: The error display is too general, and the cause of the error cannot be clearly located #706

fix(tianmu): feature: The error display is too general, and the cause of the error cannot be clearly located #706

Cause:
There is a problem with the corresponding table index when creating entity columns
Solution:
When creating an entity column, the table index you try to import corresponds to the position in the tables list one by one

    The cause of an error is
    that you need to identify the returned
    result of the exists subquery for sl->join->zero_result_cause
    Determines whether a return value exists.
    and format query.cpp
:
The exists subquery determines whether a value exists during the query optimization phase

result is not set to zero only when a matching value is found in the query optimization phase

When a field has an index, the optimization phase scans the table through the index

The primary key implementation of the current column storage engine has a problem with the primary key index to scan the table for data

As a result, the primary key index is used to obtain the exists subquery result in the query optimization phase. Therefore, the exists subquery is not executed in the query execution phase

scan the table for data Remove the following temporary practices after primary key indexing is complete

Replace the function FindCurrentRowByVMTable that gets the current row to FindCurrentRow.

feat(tianmu)The tianmu engine throws exception modification and specific exception information to the client

Cause:
no_dims is a destination number of dimensions.
It needs to be increased according to the number of executions.
But the logic here is that whether the table is involved in execution or not, it will lead to the increase of (no_dims),
This in turn causes the subsequent pack index to exceed the length of the index array.
Solution:
Optimize the logic of (no_dims) increasing to make it increase reasonably

style(clangformat): change the parameter of clangformat AllowShortIfStatementsOnASingleLine to Never

Cause:
Execution plan error when AND/OR sql logical operator in condition occurs at the same time
Resolvent:
Optimize multiple equal execution plan logic

Cause of the problem:
The tianmu engine created join objects in syntax optimization, but did not explain them
Modify Scheme:
Release the join object after use

refine the return comment description

Cause of the problem:
In the mode where the type is ref, the line number returned by the tianmu engine is 10 by default.
Modify Scheme:
Delete the logic that returns 10 rows by default, and return the number of rows in the table instead.

[summary]
1 change tianmu status var scope from SHOW_SCOPE_UNDEF to SHOW_SCOPE_GLOBAL;

    Test results for reference:
    https://blog.csdn.net/adofsauron/article/details/127228984?spm=1001.2014.3001.5501

    TODO: Q4 and Q21
    The case is an exists subquery
    because the Tianmu engine converts
    the syntax tree to an inner join
    on an association surface.
    For details, see
    https://blog.csdn.net/adofsauron/article/details/127228984?spm=1001.2014.3001.5501

fix(handler): fix the bug for create table #mysql50#q.q should return failure and actually return success (#487)
	[summary]
	1.When creating a table in the tianmu engine, add code to determine whether the table name is empty.
	2.Add issue corresponding to mtr test case.

[summary]
1 innodb(in 5.7) system variable "innodb_large_prefix" default value is ON, follow it;

    Switches are added to support controlling whether multithreading is used to nested loops

    The reason for adding a parameter to control whether to enable multithreaded nested loop is that

    1. Provides parameters for fast execution of single-threaded versus multithreaded comparisons
    2. At present, the physical layer is placed in the second stage because
    the multi-threaded transformation of Nested loop has not been thoroughly carried out during the development period.
    The argument that controls turning on multithreading is also needed for easy code rollback

    TODO: There is no time to continue to optimize this parameter,
    later need to provide a configurable parameter to
    control whether to enable multithreading

fix(tianmu) Fix: The problem that the corresponding table is conditional but will still be executed (EvaluatePack_IsNoDelete)(#579)

 Cause of the problem
    The reason for this problem is that when (ParameterizedFilter:: UpdateMultiIndex()) starts,
    (desc. attr. vc ->GetVarMap()) There is a problem with the size judgment of size().
    It should be>=1, but it is written as>1. Each filter logic will go to (FilterDeletedByTable).

 Solution
    Modify the judgment condition to>=1

    The current version does not enable multithreaded aggregation optimization,
    Here's why:
    Currently, for multi-thread parallel,
    it is not completely carried out to the physical layer,
    for DPN and PACK data structure,
    because the underlying physical block processing for multi-thread from the data structure support is missing,
    when a multi-thread switch occurs,
    the data that has been read out is reset.
    More time is needed to support parallel read IO across multiple threads from the underlying data structures,
    which is not available in the current version,
    so we plan to start the second phase of the multi-thread read IO process completely.

The logic of this modification is as follows:

Descriptor object, MIUpdatingIterator object and DimensionVector are all newly defined objects this time. If you want iterators to work, you must have corresponding DimGroups. Because I didn't fully understand the usage of these classes, I used (dims. SetAll()) to set them, causing all DimGroups to converge.

The modification method is to use the corresponding virtual column to set DimGroups, so that the data volume is at most the data volume of the current table

* feat(tianmu) Add upgrade directory (#510)

* Optimize the structure of DPN to support memory alignment

feat(tianmu) Refactor the aggregation and The IN operator to multithread #472 (#422 #465 #466) (#472)

* Refactor the aggregation to multithread
Co-authored-by: Nhustjieke <gaoriyao1@gmail.com>