[MCOL-4614] calShowPartitions() precision loss for huge narrow decimal Created: 2021-03-16  Updated: 2021-06-14  Resolved: 2021-06-14

Status: Closed
Project: MariaDB ColumnStore
Component/s: PrimProc
Affects Version/s: 5.5.1, 5.6.1
Fix Version/s: 6.1.1

Type: Bug Priority: Major
Reporter: Alexander Barkov Assignee: Daniel Lee (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocks
blocks MCOL-4361 Replace pow(10.0, (double)scale) expr... Closed
Relates
relates to MCOL-4673 Regression: calShowPartition returns N/A Closed
Sprint: 2021-5, 2021-6, 2021-7, 2021-8

 Description   

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (a DECIMAL(17,1)) ENGINE=ColumnStore;
INSERT INTO t1 VALUES (-8999999999999999.9);
SELECT * FROM t1 WHERE a=0;
SELECT calShowPartitions('t1','a');

+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| calShowPartitions('t1','a')                                                                                                                                  |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Part#     Min                           Max                           Status
  0.0.1     -9000000000000000.0           -9000000000000000.0           Enabled |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+

Notice, the Min and Max values are wrong.

This happens because the underlying printing code uses double representation.

It should be fixed to use native representation.



 Comments   
Comment by Alexander Barkov [ 2021-03-20 ]

gdorman No. It's a bug in the narrow decimal code. It needs to be fixed.

Comment by Gagan Goel (Inactive) [ 2021-04-06 ]

For QA: Instructions to reproduce the issue and verify the fix works are in the issue description.

Comment by Daniel Lee (Inactive) [ 2021-04-09 ]

Build verified: 6.1.1 ( Drone #2104 )

Reproduced the issue in 5.5.2-1

The query did not set the casual partitioning's min/max values. Could this be related to MCOL-2044?

MariaDB [mytest]> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected (0.208 sec)
 
MariaDB [mytest]> CREATE TABLE t1 (a DECIMAL(17,1)) ENGINE=ColumnStore;
Query OK, 0 rows affected (0.142 sec)
 
MariaDB [mytest]> INSERT INTO t1 VALUES (-8999999999999999.9);
Query OK, 1 row affected (0.103 sec)
 
MariaDB [mytest]> SELECT * FROM t1 WHERE a=0;
Empty set (0.058 sec)
 
MariaDB [mytest]> SELECT calShowPartitions('t1','a');
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| calShowPartitions('t1','a')                                                                                                                                  |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Part#     Min                           Max                           Status
  0.0.1     N/A                           N/A                           Enabled |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.002 sec)

Comment by Sergey Zefirov [ 2021-04-09 ]

Re: could it be related to MCOL-2044.

It may. Let me look at it.

Comment by Sergey Zefirov [ 2021-04-09 ]

I have this result:

...there was a CREATE TABLE statement...
MariaDB [test]> INSERT INTO t1 VALUES (-8999999999999999.9),(-899999999999999.9);
Query OK, 2 rows affected (0.211 sec)
Records: 2  Duplicates: 0  Warnings: 0
 
MariaDB [test]> select * from information_schema.columnstore_extents;
+-----------+-------------+---------------------+-------------------+--------------------+-------------------+-------+--------+--------------+------------+--------------+------------+-----------------+-------+-----------+-----------+
| OBJECT_ID | OBJECT_TYPE | LOGICAL_BLOCK_START | LOGICAL_BLOCK_END | MIN_VALUE          | MAX_VALUE         | WIDTH | DBROOT | PARTITION_ID | SEGMENT_ID | BLOCK_OFFSET | MAX_BLOCKS | HIGH_WATER_MARK | STATE | STATUS    | DATA_SIZE |
+-----------+-------------+---------------------+-------------------+--------------------+-------------------+-------+--------+--------------+------------+--------------+------------+-----------------+-------+-----------+-----------+
|      3005 | Column      |              234496 |            242687 | -90000000000000000 | -8999999999999999 |     8 |      1 |            0 |          0 |            0 |       8192 |               0 | Valid | Available |         0 |
+-----------+-------------+---------------------+-------------------+--------------------+-------------------+-------+--------+--------------+------------+--------------+------------+-----------------+-------+-----------+-----------+
1 row in set (0.028 sec)
 
MariaDB [test]> SELECT calShowPartitions('t1','a');
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| calShowPartitions('t1','a')                                                                                                                                  |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Part#     Min                           Max                           Status
  0.0.1     -8999999999999999.9           -899999999999999.9            Enabled |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.024 sec)

INSERT INTO t1 VALUES (-8999999999999999.9),(-899999999999999.9); inserts two values and sets extentmap ranges. Then calShowPartitions works.

What does not work is the scanning part of SELECT * FROM t1 WHERE a=0. After that query ranges stay the same - invalid range and marked as invalid.

Comment by Sergey Zefirov [ 2021-04-09 ]

A script to demonstrate the problem:

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (a DECIMAL(17,1)) ENGINE=ColumnStore;
INSERT INTO t1 VALUES (-8999999999999999.9);
 
SELECT * FROM information_schema.columnstore_extents; -- should show invalid range for extent with the value.
 
SELECT * FROM t1 WHERE a=0;
SELECT * FROM information_schema.columnstore_extents; -- should show valid range (scanned during previous select) but it does not.

Comment by Alexander Barkov [ 2021-06-10 ]

dleeyh, can you please test again? The problem with calShowPartitions() displaying N/A instead of numbers was fixed by Sergey. Thanks.

Comment by Daniel Lee (Inactive) [ 2021-06-14 ]

Build verified: 6.1.1 ( Drone #2584)

MariaDB [mytest]> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected (0.523 sec)

MariaDB [mytest]> CREATE TABLE t1 (a DECIMAL(17,1)) ENGINE=ColumnStore;
Query OK, 0 rows affected (0.603 sec)

MariaDB [mytest]> INSERT INTO t1 VALUES (-8999999999999999.9);
Query OK, 1 row affected (0.554 sec)

MariaDB [mytest]> SELECT * FROM t1 WHERE a=0;
Empty set (0.057 sec)

MariaDB [mytest]> SELECT calShowPartitions('t1','a');
--------------------------------------------------------------------------------------------------------------------------------------------------------------

calShowPartitions('t1','a')

--------------------------------------------------------------------------------------------------------------------------------------------------------------

Part# Min Max Status
0.0.1 -8999999999999999.9 -8999999999999999.9 Enabled

--------------------------------------------------------------------------------------------------------------------------------------------------------------
1 row in set (0.002 sec)

Generated at Thu Feb 08 02:51:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.