You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "C. Scott Andreas (Jira)" <ji...@apache.org> on 2020/01/18 01:42:00 UTC
[jira] [Commented] (CASSANDRA-15503) Slow query log indicates
opposite LTE when GTE operator
[ https://issues.apache.org/jira/browse/CASSANDRA-15503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018464#comment-17018464 ]
C. Scott Andreas commented on CASSANDRA-15503:
----------------------------------------------
Confirmed this reproduces on 3.11.5, affecting strict equalities as well.
Strict equality expressions aren't printed at all:
{{cqlsh> select * from test.atable where timestamp = '1975-01-01 00:00:00.006+0000' allow filtering;}}
{{=> <SELECT * FROM test.atable WHERE LIMIT 100>, time 11 msec - slow timeout 1 msec/cross-node}}
And as Wallace notes, inequalities are reversed:
{{cqlsh> select * from test.atable where timestamp > '1975-01-01 00:00:00.006+0000' allow filtering;}}
{{=> <SELECT * FROM test.atable WHERE timestamp < 1974-12-31 16:00-0800 LIMIT 100>, time 11 msec - slow timeout 1 msec/cross-node}}
> Slow query log indicates opposite LTE when GTE operator
> -------------------------------------------------------
>
> Key: CASSANDRA-15503
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15503
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
> Reporter: Wallace Baggaley
> Priority: Normal
>
> Slow query log is indicating a '<=' when a ">=" operator was sent. This appears to be a logging only issue, but it threw off development for a day figuring this out. Please fix.
> How to reproduce. Set slow query log timeout to 1 millisecond.
> In cqlsh run
> {noformat}
> CREATE TABLE atable (
> .id text,
> timestamp timestamp,
> PRIMARY KEY ((id), timestamp)
> ) WITH CLUSTERING ORDER BY (timestamp DESC);
> insert into atable (id, timestamp) VALUES ( '1',1);
> insert into atable (id, timestamp) VALUES ( '2',2);
> insert into atable (id, timestamp) VALUES ( '3',3);
> insert into atable (id, timestamp) VALUES ( '4',4);
> insert into atable (id, timestamp) VALUES ( '5',5);
> insert into atable (id, timestamp) VALUES ( '6',6);
> insert into atable (id, timestamp) VALUES ( '7',7);
> insert into atable (id, timestamp) VALUES ( '8',8);
> insert into atable (id, timestamp) VALUES ( '9',9);
> insert into atable (id, timestamp) VALUES ( '10',10);
> insert into atable (id, timestamp) VALUES ( '11',11);
> select * from atable where timestamp >= '1970-01-01 00:00:00.006+0000' allow filtering;
> {noformat}
> In the logs it prints:
> {noformat}
> DEBUG 1 operations were slow in the last 5003 msecs:
> <SELECT * FROM ks.atable WHERE timestamp <= 1970-01-01 00:00Z LIMIT 100>, time 7 msec - slow timeout 1 msec
> {noformat}
> But the query works appropriately and returns
> {noformat}
> id | timestamp
> ----+---------------------------------
> 6 | 1970-01-01 00:00:00.006000+0000
> 7 | 1970-01-01 00:00:00.007000+0000
> 9 | 1970-01-01 00:00:00.009000+0000
> 10 | 1970-01-01 00:00:00.010000+0000
> 8 | 1970-01-01 00:00:00.008000+0000
> 11 | 1970-01-01 00:00:00.011000+0000
> (6 rows)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org