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.
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.
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.
2. Set 100k as the batch size when flushing records into ColumnStore, i.e.,
a flush of 1M records will be performed in 10 batches, each being 100k.
3. For INSERT ... SELECT on the cache, use the default insertion method of cpimport.
For certain queries, such as:
update cs1 set i = 41 where i = 42 or (i is null and 42 is null);
the SELECT_LEX.where does not contain the required where conditions.
Server sends the where conditions in the call to cond_push(), so
we are storing them in a handler data member, condStack, and later
push them down to getSelectPlan() for UPDATES/DELETEs.
new value, ALWAYS, which invokes cpimport for LDI and INSERT..SELECT
from within and outside a transaction.
Default value of the session variable, ON, remains unchanged.
Original SH implementation sends the result set back to the client
thus it can't be used in INSERT..SELECT, SELECT INTO OUTFILE,CREATE
TABLE AS SELECT etc.
CLX-77 feature has been backported into MDB to enable SH to run
query part of the mentioned queries.
internally(thus can remove equi-JOIN predicates) with a recursive f()
to inject equi-JOIN conditions for IN + correlated subquery Item.
This change both solves MCOL-3747 issue and remove issues I first
faced in union.sql test.
This commit also fixes a clean up for conditions pushed for table API
execution path and replaces NULL with nullptr in ha_mcs_impl.cpp.
Several changes have happened in MariaDB 10.5, most notably:
* Information Schema table definitions have changed
* More things use LEX_CSTRING
This fixes all the compile issues
NOT IN + correlated subquery if the subquery returns empty set.
CS now returns full outer record set.
gcc 8.2 complains about unused variable in ha_mcs_impl.cc
this is executed when ha_columnstore is loaded, at dlopen time
before any initialization code is run and crashes any dlopen
attemps.
Crashes - because a missing config file is a crashing offence,
but it's an issue for another day
Changed the row-based repl detection mechanism so stmt-based repl works
again, however, the detection mechanism is still wrong somehow. What it
should be is currently unknown.
Direct update/delete executed doUpdateDelete as well as the regular
execution route for doUpdateDelete.
This patch only executes doUpdateDelete the first time and direct
update/delete collects the counts.
