For CHAR/VARCHAR/TEXT fields, the buffer size of a field represents
the field size in bytes, which can be bigger than the field size in
number of characters, for multi-byte character sets such as utf8,
utf8mb4 etc. The buffer also contains a byte length prefix which can be
up to 65532 bytes for a VARCHAR field, and much higher for a TEXT
field (we process a maximum byte length for a TEXT field which fits in
4 bytes, which is 2^32 - 1 = 4GB!).
There is also special processing for a TEXT field defined with a default
length like so:
CREATE TABLE cs1 (a TEXT CHARACTER SET utf8)
Here, the byte length is a fixed 65535, irrespective of the character
set used. This is different from a case such as:
CREATE TABLE cs1 (a TEXT(65535) CHARACTER SET utf8), where the byte length
for the field will be 65535*3.
flag to ha_mcs_impl_start_bulk_insert.
An earlier commit to fix LDI under replication changed the call in
ha_mcs_cache::start_bulk_insert for a non-insert command from
parent::start_bulk_insert_from_cache to parent::start_bulk_insert.
This commit reverts that change for INSERT...SELECT operation.
If the plugin is restarted after the system is running, it's possible to have stale references to shared memory. This patch deletes those references so the next time they're used, just-in-time initialization will get the latest.
Mutate the optimizer flags for prepared statements in:
1. ha_mcs::open
2. ha_mcs::discover_check_version
This is done to ensure the optimizer flags are disabled before
JOIN::prepare() is called during "PREPARE stmt FROM ...".
Create tables and schemas with lower case name only if the flag is set.
During operations, convert to lowercase in plugin. Byt the time a query gets to ExeMgr, DDLProc etc., everything must be lower case if the flag is set, and undisturbed if not.
into the columnstore table, and not into the cache.
LDI performed on a master, comes in as a SQLCOM_END sql_command
on the slave, when binlog_format != STATEMENT. If the cache already
had some records, we were earlier flushing the cache for the LDI
on the slave. This patch detects whether we are in the slave
thread or not, if so, then we don't do a cache flush if
sql_command = SQLCOM_END.
This patch enables select handler for executing prepared
statements. Most importantly, we are now activating a
persistent arena which will allocate any new items in a
permanent MEMROOT for prepared statements and stored procedures.
Refer to JOIN::optimize_inner() for details.
In processWhere(), we now use SELECT_LEX::prep_where in case
we are executing a prepared statement, as this is where the saved
WHERE clause is stored for prepared statement processing.
In addition, we also disable derived handler for prepared
statements.
The change for MCOL-4264 erroneously added the "lock_type" member
to cal_connection_info, which is shared between multiple tables.
So some tables that were opened for write erroneously identified
themselves as read only.
Moving the member to ha_mcs instead.
Problem:
When processing cross-engine queries like:
update cstab1 set a=100 where a not in (select a from innotab1 where a=11);
delete from innotab1 where a not in (select a from cstab1 where a=1);
the ColumnStore plugin erroneously executed the whole query inside
ColumnStore.
Fix:
- Adding a new member cal_connection_info::lock_type and setting it
inside ha_mcs_impl_external_lock() to the value passed in the parameter
"lock_type".
- Adding a method cal_connection_info::isReadOnly() to test
if the last table lock made in ha_mcs_impl_external_lock()
for done for reading.
- Adding a new condition checking cal_connection_info::isReadOnly() inside
ha_mcs_impl_rnd_init(). If the current table was locked last time for reading,
then doUpdateDelete() should not be executed.
During data retrieval, we were type casting a field type to what we thought was the correct type. Often it was not. Since we're calling virtual functions on *f, there's no need to type cast in most cases. This was a relic from days gone by.
from server/columnstore_cache.
Commit message:
Fixed bug in free locks that caused rows in cache to not be properly flushed
Fixed by doing adding external_lock(F_UNLCK) in free_locks.
I also moved unlock of cache_handler to be after changing lock type of
cached tables to ensure that no one can use cached table while this is
happening (as cache table is locked with write lock).
I also fixed a wrong mutex order bug in ha_cache::flush_insert_cache()
Other things:
- Addded share::cached_rows to track inserted rows. This is only used
for asserts to check the number of rows in the cache.
- Fixed wrong mysql_file_chsize() in case of repair
We are creating a new read-only system variable, columnstore_cache_inserts,
to enable/disable the cache. When this variable is set at server start up,
any table created with engine=columnstore will also create the corresponding
cache table in Aria engine for performing inserts.
It is important to note that a ColumnStore table created with this
option unset should not be queried when the server is restarted with
the option set, as this will most likely result in query failures.
