Part#2: Fix a couple more issues in rows-type frames.
This also has a code cleanup:
- introduce a separate Frame_rows_current_row_(top,bottom). This is
is a special case which doesn't need its cursor or partition bound check
- Split Frame_n_rows into
= Frame_n_rows_preceding (this one is now much simpler)
= Frame_n_rows_following (simpler and works but may need some work still)
Part#1: Frame_n_rows::next_partition() should not assume that the
current table->record[0] points to the first row in the partition.
Since cursor supports move_to() operation, we dont need this.
Introduce explicitly-defined cursors.
- Rowid_seq_cursor just reads the rowid sequence
- Table_read_cursor also reads rows for the rowids
- Also, we need a kind of cursor that stops at partition boundary?
- Item_sum_count::remove() should check if the argument's value is NULL.
- Window Function item must have its Item_window_func::split_sum_func
called,
- and it must call split_sum_func for aggregate's arguments (see the
comment near Item_window_func::split_sum_func for explanation why)
- Add temporary code: clone_read_record() clones READ_RECORD structure,
as long as it is used for reading filesort() result that fits into
memory.
- Add frame bounds for ROWS-type frames. ROWS n PRECEDING|FOLLOWING,
ROWS UNBOUNDED PRECEDING|FOLLOWING, CURRENT ROW are supported.
- Add Item_sum_count::remove() which allows "streaming" computation
of COUNT() over a moving frame.
These do not have any meaning after MDEV-8646. Their only valid values are
- table_access_tabs= join_tab;
- top_table_access_tabs_count= top_join_tab_count;
Disable the code that attempts to group window functions together
by their PARTITION BY / ORDER BY clauses, because
1. It doesn't work: when I issue a query with just one window function,
and no indexes on the table, filesort is not invoked at all.
2. It is not possible to check that it works currently.
Add my own code that does invoke filesort() for each window function.
- Hopefully the sort criteria is right
- Debugging shows that filesort operates on {sort_key, rowid} pairs (OK)
- We can read the filesort rowid result in order.
"Re-factor the code for post-join operations".
The patch mainly contains the code ported from mysql-5.6 and
created for two essential architectural changes:
1. WL#5558: Resolve ORDER BY execution method at the optimization stage
2. WL#6071: Inline tmp tables into the nested loops algorithm
The first task was implemented for mysql-5.6 by Ole John Aske.
It allows to make all decisions on ORDER BY operation at the optimization
stage.
The second task implemented for mysql-5.6 by Evgeny Potemkin adds JOIN_TAB
nodes for post-join operations that require temporary tables. It allows
to execute these operations within the nested loops algorithm that used to
be used before this task only for join queries. Besides these task moves
all planning on the execution of these operations from the execution phase
to the optimization phase.
Some other re-factoring changes of mysql-5.6 were pulled in, mainly because
it was easier to pull them in than roll them back. In particular all
changes concerning Ref_ptr_array were incorporated.
The port required some changes in the MariaDB code that concerned the
functionality of EXPLAIN and ANALYZE. This was done mainly by Sergey
Petrunia.
MDEV-9408 CREATE TABLE SELECT MAX(int_column) creates different columns for table vs view
There were three almost identical pieces of the code:
- Field *Item_func::tmp_table_field();
- Field *Item_sum::create_tmp_field();
- Field *create_tmp_field_from_item();
with a difference in very small details (hence the bugs):
Only Item_func::tmp_table_field() was correct, the other two were not.
Removing the two incorrect pieces of the redundant code.
Joining these three functions/methods into a single virtual method
Item::create_tmp_field().
Additionally, moving Item::make_string_field() and
Item::tmp_table_field_from_field_type() from the public into the
protected section of the class declaration, as they are now not
needed outside of Item.
Also fixes:
MDEV-9391 InnoDB does not produce warnings when doing WHERE int_column=varchar_column
MDEV-9337 ALTER from DECIMAL and INT to DATETIME returns a wrong result
MDEV-9340 Copying from INT/DOUBLE to ENUM is inconsistent
MDEV-9392 Copying from DECIMAL to YEAR is not consistent about warnings
