For a query of the form:
SELECT COUNT(c2) FROM (SELECT * FROM t1) q;
where t1 contains 10 columns c1, c2, ... , c10.
We currently create an intermediate RowGroup in ExeMgr with
a row of the form (1, c2_value1, 1, 1, 1, 1, 1, 1, 1, 1), i.e.
for all the columns of the subquery which are not referenced in
the outer query, we substitute a constant value, which is wasteful.
With this optimization, we are trimming the RowGroup to a row
of the form (1, c2_value1). This can have non-trivial query
execution time improvements if the subquery contains large number
of columns (such as a "select *" on a very wide table) and the outer
query is only referencing a subset of these columns with lower
index values from the subquery (as an example, c1 or c2 above).
That is, the current limitation of this optimization is we are not
removing those non-referenced subquery columns (c1 in the query above)
which are to the left of a referenced column.
After the cleanup work done for FETCH FIRST ... WITH TIES
SELECT_LEX members select_limit, explicit_limit and offset_limit are now moved
to SELECT_LEX::limit_params.
type is not LEFT/RIGHT.
In buildOuterJoin(), do not add ON expressions for WHERE
processing when the JOIN type is not LEFT/RIGHT.
Test cases to check correct processing of INNER JOIN ON expressions
with possible/impossible WHERE conditions are added for
1. One side of the LEFT JOIN being INNER JOIN.
2. One side of the LEFT JOIN being an INNER JOIN inside an INNER JOIN.
3. Both sides of the LEFT JOIN being an INNER JOIN.
An INSERT .. SELECT performed on a master node caused an infinite
loop on the slave node with columnstore_replication_slave=OFF.
The issue was ha_mcs_impl_select_next() was returning 0 if
the executing thread is a slave and returning early to avoid DML
execution on the slave. The calling code in select_handler::execute()
ran into an infinite loop due to this as it checked the return code
of the function as 0, and incorrectly thought there are more rows
to process.
The fix is to return HA_ERR_END_OF_FILE as the return value,
instead of 0. This is for the case of the query running on the
slave node with columnstore_replication_slave=OFF.
For TIMESTAMP, it should do similar. However, it didn't work. For some reason, MDB has the function set as DATETIME, which for cs, isn't the same thing. Added a kludge to ha_mcs_execplan.cpp to handle it.
1. This patch adds support for wide decimals with/without scale
to cpimport. In addition, INSERT ... SELECT and LDI are also
now supported.
2. Logic to compute the number of bytes to convert a binary
representation in the buffer to a narrow decimal is also
simplified.
for a generated replacement statements of original statements:
* `CREATE TABLE .. LIKE ..`
* `ALTER TABLE .. ENGINE=Columnstore`
* `CREATE TABLE .. AS ..`
MCOL-2000 Process charset definitions in the ALTER TABLE .. ADD COLUMN
MCOL-2000 Yet another fixes for column charsets
* make respect for column (including table/db/server default) charsets
for the TEXT(n) fields
* round TEXT(n) column length up to the next default length of TEXT-like
subtypes, 255 (TINYTEXT), 65535 (TEXT) and so on up to 2100000000
(LONGTEXT)
1. Add wide decimal support to AggregateColumn::evaluate
and TreeNode::getDecimalVal().
2. Use the pm aggregate attributes to determine um aggregate
attributes in TupleAggregateStep::prep2PhasesAggregate.
MCOL-4409 This patch combines VDecimal and Decimal and makes
IDB_Decimal an alias for the result class
MCOL-4409 More boilerplate reduction in Func_mod
Removed couple TSInt128::toType() methods
- The code in ha_mcs_partition.cpp erroneously printed data
to a temporary ostringstream "oss" instead of "output".
- The left-side adjustfield (applied when printing the range values)
unintentionally disappeared during MCOL-4174 refactoring.
Restoring left adjustfield in TypeHandler::PrintPartitionValue*().
For now it consists of only:
using int128_t = __int128;
using uint128_t = unsigned __int128;
All new privitive data types should go into this file in the future.
1. Perform type promotion to wide decimal if the result
of an arithmetic operation has a precision > 18.
2. Only set the decimal width of an arithmetic operation to wide
if both the LHS and RHS of the operation are decimal types.
This commit also adds support in TupleHashJoinStep::forwardCPData,
although we currently do not support wide decimals as join keys.
Row estimation to determine large-side of the join is also updated.
Introduced fDecimalOverflowCheck to enable/disable overflow check.
Add support into a FunctionColumn.
Low level scanning crashes on medium sized data sets.
2. Set Decimal precision in SimpleColumn::evaluate().
3. Add support for int128_t in ConstantColumn.
4. Set IDB_Decimal::s128Value in buildDecimalColumn().
5. Use width 16 as first if predicate for branching based on decimal width.
