The idea is that instead of marking all select_lex's with DISTINCT, we
only mark those that really need distinct result.
Benefits of this change:
- Temporary tables used with derived tables, UNION, IN are now smaller
as duplicates are removed already on the insert phase.
- The optimizer can now produce better plans with EQ_REF. This can be
seen from the tests where several queries does not anymore materialize
derived tables twice.
- Queries affected by 'in_predicate_conversion_threshold' where large IN
lists are converted to sub query produces better plans.
Other things:
- Removed on duplicate call to sel->init_select() in
LEX::add_primary_to_query_expression_body()
- I moved the testing of
tab->table->pos_in_table_list->is_materialized_derived()
in join_read_const_table() to the caller as it caused problems for
derived tables that could be proven to be const tables.
This also is likely to fix some bugs as if join_read_const_table()
was aborted, the table was left marked as JT_CONST, which cannot
be good. I added an ASSERT there for now that can be removed when
the code has been properly tested.
MDEV-27036: repeated "table" key resolve for print_explain_json
MDEV-27036: duplicated keys in best_access_path
MDEV-27036: Explain_aggr_filesort::print_json_members: resolve duplicated "filesort" member in Json object
MDEV-27036: Explain_basic_join::
print_explain_json_interns fixed start_dups_weedout case for main.explain_json test
When executing set operations in a pipeline using only one temporary table
additional scans of intermediate results may be needed. The scans are
performed with usage of the rnd_next() handler function that might
leave record buffers used for the temporary table not in a state that
is good for following writes into the table. For example it happens for
aria engine when the last call of rnd_next() encounters only deleted
records. Thus a cleanup of record buffers is needed after each such scan
of the temporary table.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
