- 12 Dec, 2016 40 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
* do setup/cleanup for charset and arena only once per table not for every vcol * don't copy every vcol expression into table's memroot for parsing, do it in a temporary String buffer that is freed at the end * add asserts
-
Sergei Golubchik authored
now, when expr_str is gone, expr_item can be unambiguously renamed to expr.
-
Sergei Golubchik authored
otherwise we'd need to store sql_mode *per vcol* (consider CREATE INDEX...) and how SHOW CREATE TABLE would support that? Additionally, get rid of vcol::expr_str, just to make sure the string is always generated and never leaked in the original form.
-
Sergei Golubchik authored
it must, because purge opens a table that might be being altered right now
-
Sergei Golubchik authored
* remove old 5.2+ InnoDB support for virtual columns * enable corresponding parts of the innodb-5.7 sources * copy corresponding test cases from 5.7 * copy detailed Alter_inplace_info::HA_ALTER_FLAGS flags from 5.7 - and more detailed detection of changes in fill_alter_inplace_info() * more "innodb compatibility hooks" in sql_class.cc to - create/destroy/reset a THD (used by background purge threads) - find a prelocked table by name - open a table (from a background purge thread) * different from 5.7: - new service thread "thd_destructor_proxy" to make sure all THDs are destroyed at the correct point in time during the server shutdown - proper opening/closing of tables for vcol evaluations in + FK checks (use already opened prelocked tables) + purge threads (open the table, MDLock it, add it to tdc, close when not needed) - cache open tables in vc_templ - avoid unnecessary allocations, reuse table->record[0] and table->s->default_values - not needed in 5.7, because it overcalculates: + tell the server to calculate vcols for an on-going inline ADD INDEX + calculate vcols for correct error messages * update other engines (mroonga/tokudb) accordingly
-
Sergei Golubchik authored
remove 'table' argument, remnant of 5.6, does not exist in 5.7
-
Sergei Golubchik authored
* remnant of 5.6, does not exist in 5.7. bad merge? * also remove dict_table_get_col_name_for_mysql(), it was only used when index_field_t::col_name was not NULL
-
Sergei Golubchik authored
* fix "unused pending_checkpoint_mutex_key" compiler warning * clarify/simplify get_field_offset() * typos, comments * unused (forgotten) declaration of create_options_are_invalid() * fix my_error(ER_WRONG_KEY_COLUMN) calls * crash in row_upd_sec_index_entry() * double if (ret != 0) * don't duplucate PSI_INSTRUMENT_ME lines * useless break; after return(); * remove unused xtradb-only "cursor_read_view" stuff * code formatting * simplify dropped column detection * redundant assignment
-
Sergei Golubchik authored
and THD::inc_thread_count
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
Use TABLE::init_one_table(), don't duplicate it. Put additional initializations into TABLE::init_one_table_for_prelocking()
-
Sergei Golubchik authored
instead of returning strings for CASCADE/RESTRICT from every storage engine, use enum values
-
Sergei Golubchik authored
* wrong results for 5.7 and 10.1- vcols, and for indexed vcols * only helps in rare cases and only minimally
-
Sergei Golubchik authored
partitioning was setting subj as a partitioning-specific hack (GET_FIXED_FIELDS_FLAG field flag to detect partitioning fields) inside init_lex_with_single_table(). But vcols also use init_lex_with_single_table(), they run fix_fields() in open_table_from_share() before partitioning and this messes up partitioning GET_FIXED_FIELDS_FLAG logic.
-
Sergei Golubchik authored
When updating a table with virtual BLOB columns, the following might happen: - an old record is read from the table, it has no virtual blob values - update_virtual_fields() is run, vcol blob gets its value into the record. But only a pointer to the value is in the table->record[0], the value is in Field_blob::value String (but it doesn't have to be! it can be in the record, if the column is just a copy of another columns: ... b VARCHAR, c BLOB AS (b) ...) - store_record(table,record[1]), old record now is in record[1] - fill_record() prepares new values in record[0], vcol blob is updated, new value replaces the old one in the Field_blob::value - now both record[1] and record[0] have a pointer that points to the *new* vcol blob value. Or record[1] has a pointer to nowhere if Field_blob::value had to realloc. To resolve this we unlink vcol blobs from the pointer to the data (in the record[1]). Because the value is not *always* in the Field_blob::value String, we need to remember what blobs were unlinked. The orphan memory must be freed manually. To complicate the matter, ha_update_row() is also used in multi-update, in REPLACE, in INSERT ... ON DUPLICATE KEY UPDATE, also on REPLACE ... SELECT, REPLACE DELAYED, and LOAD DATA REPLACE, etc
-
Sergei Golubchik authored
multi-update was setting up read_set/vcol_set in multi_update::initialize_tables() that is invoked after the optimizer (JOIN::optimize_inner()). But some rows - if they're from const tables - will be read already in the optimizer, and these rows will not have all necessary column/vcol values. * multi_update::initialize_tables() uses results from the optimizer and cannot be moved to be called earlier. * multi_update::prepare() is called before the optimizer, but it cannot set up read_set/vcol_set, because the optimizer might reset them (see SELECT_LEX::update_used_tables()). As a fix I've added a new method, select_result::prepare_to_read_rows(), it's called from inside the optimizer just before make_join_statistics().
-
Sergei Golubchik authored
This fixes a bug where handler::read_range_first (for example) needed to compare vcol values that were not calculated yet. As a bonus it fixes few cases where vcols were calculated twice
-
Sergei Golubchik authored
sql_insert.cc calls handler->ha_update_row() for REPLACE and INSERT... ON DUPLICATE KEY UPDATE
-
Sergei Golubchik authored
-
Sergei Golubchik authored
cannot use TABLE:merge_keys for that, because Field::part_of_key was designed to mark fields for KEY_READ, so a field is not a "part of key", if only prefix of the field is.
-
Sergei Golubchik authored
* don't issue an error for ER_KEY_BASED_ON_GENERATED_VIRTUAL_COLUMN * support keyread on vcols * callback into the server to compute vcol values from mi_check/mi_repair * DMLs just work. Automatically.
-
Sergei Golubchik authored
update tests and results, fix bugs
-
Sergei Golubchik authored
-
Sergei Golubchik authored
will be used later by storage engines (e.g. in MyISAM repair or in InnoDB purge)
-
Sergei Golubchik authored
because it's only doing to show the table structure, not look at the data.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
always set them according to the repair method used
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
and declare few other Field getters to be 'const'
-
Sergei Golubchik authored
Make update_virtual_fields() a method of TABLE, to be consistent with TABLE::update_default_fields().
-
Sergei Golubchik authored
TABLE::mark_virtual_col() was polluting table->vcol_set and that confused the following mark_virtual_col()
-
Sergei Golubchik authored
-