Hi, Sergey! On Sep 06, Sergey Vojtovich wrote:
revno: 3878 revision-id: svoj@mariadb.org-20130906111656-oy2c3pwy2o1q0zqn parent: wlad@montyprogram.com-20130903204512-hgwu77prle0lw7a3 committer: Sergey Vojtovich <svoj@mariadb.org> branch nick: 5.5-mdev4978 timestamp: Fri 2013-09-06 15:16:56 +0400 message: MDEV-4978 - Server cursor is broken with blobs in the select list, ORDER BY does not work
Use "dynamic" row format (instead of "block") for MARIA internal temporary tables created for cursors. With "block" row format MARIA may shuffle rows, with "dynamic" row format records are inserted sequentially (there are no gaps in data file while we fill temporary tables). This is needed to preserve row order when scanning materialized cursors.
=== modified file 'sql/sql_select.cc' --- a/sql/sql_select.cc 2013-09-03 14:41:07 +0000 +++ b/sql/sql_select.cc 2013-09-06 11:16:56 +0000 @@ -15373,7 +15374,8 @@ create_tmp_table(THD *thd, TMP_TABLE_PAR if (thd->is_fatal_error) // If end of memory goto err; /* purecov: inspected */ share->db_record_offset= 1; - table->used_for_duplicate_elimination= (param->sum_func_count == 0 && + table->used_for_duplicate_elimination= keep_row_order || + (param->sum_func_count == 0 && (table->group || table->distinct));
That's very confusing. Why keep_row_order means that the table is "used for duplicate elimination"? I had to check the code to see that used_for_duplicate_elimination affects the row format in Aria. This is not obvious too. And it forces the row format to be DYNAMIC for a very different reason, not for preserving row order. Perhaps it'd be better to rename used_for_duplicate_elimination to "force_dynamic_Aria_row_format" ? A prettier solution would be to introduce another flag: table->keep_row_order. Regards, Sergei