This may or may not be an edge case. Much more testing with various scenarios needs to done.
After running the following multiple times:
cpimport tpch1 partsupp -s '|' '/home/calpont/partsupp.tbl'
where partsupp.tbl is a 10g generated file,
we can get erroneous numbers for count. This doesn't always happen. It has been observed in both compressed and uncompressed tables. The count, when incorrect, is always smaller than the actual count and is underreported by a multiple of 2048. Restarting the system after the count is reported incorrectly corrects the issue.
The phenomenon has been seen using various load sequences, but the most consistent sequence that breaks it is:
Using uncompressed table, single user, 4 dbroots with partsupp.tbl a generated 10g file.
MariaDB [tpch1]> truncate table partsupp;
cpimport tpch1 partsupp -s '|' '/home/calpont/partsupp.tbl'
MariaDB [tpch1]> select idbDBRoot(ps_partkey) dbroot, idbExtentId(ps_partkey) extent, count
from partsupp group by dbroot, extent order by dbroot, extent;
------------------------
| dbroot | extent | count |
------------------------
| 4 | 13304832 | 8000000 |
------------------------
1 row in set (1.35 sec)
cpimport tpch1 partsupp -s '|' '/home/calpont/partsupp.tbl'
MariaDB [tpch1]> select count from partsupp;
----------
| count |
----------
| 15997952 |
----------
1 row in set (0.70 sec)