The old procedure could be wildly incorrect when there were multiple
extents for a dictionary column.
The new one uses tables so that columnstore_files doesn't get
hammered too hard. They can't be temporary tables due to the reuse
restriction on temporary tables.
This does the following:
* Switch resource manager to a singleton which reduces the amount of
times the XML data is scanned and objects allocated.
* Make the I_S tables use the FE implementation of the system catalog
* Make the I_S.columnstore_columns table use the RID list cache
* Make the extentmap pre-allocate a vector instead of many small allocs
It is possible for a BLOB/TEXT column to appear in a cross engine join.
This causes an ExeMgr crash later during execution. For now this patch
disable BLOB/TEXT support.
This patch allows the following syntax to change the current
autoincrement value for the table:
ALTER TABLE table_name COMMENT='autoincrement=value';
Where "value" is the new integer to be used.
Arithmatic on two functions inside an aggregate function caused an error
due to the function not being parsed correctly. This fix parses the
function for the arithmatic.
I_S.COLUMNSTORE_FILES returned bad filenames and NULL file sizes when
there are multiple nodes in a ColumnStore cluster
It adds an extra message call to the WriteEngine to get the file size
for that file. The I_S function will figure out which WriteEngine to
communicate with and get the file size details from it.
When a table has 8 columns that could be NULL and a NOT NULL column
after the NULLable columns the check to see if we have gone over the
NULL bitmap byte limit is run prematurely trigging an error.
This patch moves the check to only run when we are looking at NULLable
columns.
table_usage() is now called using:
* table_usage(NULL, NULL) - all tables
* table_usage(NULL, 'table') - match tables with the name 'table' in all
schemas
* table_usage('schema', 'table') - match a specific schema and table
combination
Fixes the following:
* Compression ratio calculation was incorrect
* Possible issues due to system catalog thread ID usage
* Compressed file size data count was leaking many FDs when the table
wasn't compressed
* Compressed file size data count was allocating random large amounts
of RAM and then leaking it when the table wasn't compressed
* Add INFORMATION_SCHEMA.COLUMNSTORE_FILES which contains information
about files
* Remove file information from COLUMNSTORE_EXTENTS (due to above)
* Hide columns with Object ID < 3000 (internal columns)
* Fix bad calculation in data_size columns
* Fix minor memory leak
* Add compressedSize() function to IDBFileSystem to get the used file
size for a compressed file
* Add columnstore_info schema with utility stored procedures to access
the information_schema tables
This patch does the following:
* Fix a year storage issue in the datestamp for the columnstore tables
metadata table (note that any previous tables will still have the
incorrect year stored).
* Expose the table creation date in CalpontSystemCatalog::getTables()
* Add an INFORMATION_SCHEMA table listing the tables in ColumnStore
(similar to systable)
* Add an INFORMATION_SCHEMA table listing the columns in ColumnStore
(similar to syscolumn)
* Add an INFORMATION_SCHEMA table listing the extents in ColumnStore
(similar to the editem tool but with additional file information)
* Modifies the build system and scripts to support the new tables
This changes the warning for truncation to the correct MariaDB error
code (1264).
In addition it passes the strict mode up into the DML class to roll back
correctly.
It also sets the abort_on_warning flag for updates as this isn't set on
the rnd_init phase but is needed for strict mode to work.
Datetime has internal int value which is very different to MySQL's int
value. This patch differentiates between the two and also fixes a column
width issue which appeared once the datetime handling was fixed.
When infinidb_use_import_for_batchinsert is enabled the NULL handling
for the batch insert was incorrect. This is due to an off-by-one on the
NULL bitmap. This also affects INSERT...SELECT.
NULL is now pushed through the MariaDB storage engine plugin down to the
insert processing. A '0000-00-00' date is now a separate value to NULL.
This is more in-line with MariaDB's handling.
