SummingMergeTree behavior for rows having sum(col) = 0

[mystic m]

I tried a variation of this example for SummingMergeTree to reproduce the problem I am seeing with my data, https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00043_summing_empty_part.sql

Here are the steps and outcome -

1. CREATE TABLE test.m1 (d Date, k UInt64, v Int8) ENGINE=SummingMergeTree(d, k, 8192);
   
2. INSERT INTO test.m1 VALUES ('2015-01-01', 1, 10);
   
3. INSERT INTO test.m1 VALUES ('2015-01-01', 1, -10);
   
4. select * from test.m1
   

2015-01-01 â 1 â 0 â

Output remains same even when optimize table is applied, next I ingest a record with different key-

       5. INSERT INTO test.m1 VALUES ('2015-01-01', 2, 2);

Immediately after insertion if I do a select *, I get following two records in o/p, however if I execute 'optimize table test.m1' and then fire 'select *', the record with k=1 just vaishes and there is just one single row in o/p.

 2015-01-01 â 1 â 0 â

 2015-01-01 â 2 â 2 â

This behavior makes data inconsistent for my usecase and I am unable to understand the rationale behind it. Why does step 4 not eliminate the record with sum = 0?

Is zero considered null in SummingMergeTree?

Can someone help me here, am I missing anything?

[Александр Сапин]

This behaviour is documented:

If the values were null in all of these columns, the row is deleted. (The exception is cases when the data part would not have any rows left in it.)

четверг, 2 августа 2018 г., 12:26:50 UTC+3 пользователь mystic m написал:

[mystic m]

Thanks I did read this line in documentation but why does it treat 0 as null?

[Александр Сапин]

I don't know and I think it is better to change this sentence.

четверг, 2 августа 2018 г., 15:07:33 UTC+3 пользователь mystic m написал: