You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Avi Kivity (JIRA)" <ji...@apache.org> on 2019/07/27 11:17:00 UTC

[jira] [Commented] (CASSANDRA-15250) Large cartesian produces in IN queries cause the server to run out of memory

    [ https://issues.apache.org/jira/browse/CASSANDRA-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894414#comment-16894414 ] 

Avi Kivity commented on CASSANDRA-15250:
----------------------------------------

Note: low priority as far as I am concerned, I just hit the same problem in Scylla and saw that Cassandra is also vulnerable and so reported it.

 

It should be possible to serve such large queries by giving up the sort-by-token order and not materializing the cartesian product, but it's simpler to just limit the number of rows.

> Large cartesian produces in IN queries cause the server to run out of memory
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-15250
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15250
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL/Interpreter
>            Reporter: Avi Kivity
>            Priority: Normal
>
> The queries
>  
> {{    create table tab (pk1 int, pk2 int, pk3 int, pk4 int, pk5 int, pk6 int, pk7 int, pk8 int, pk9 int, primary key((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)));}}
>  
> {{    select * from tab where pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) and pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) ; }}
>  
> Will cause the server to enter a garbage collection spiral from which it does not recover. The queries generate a large (1 billion row) cartesian product which the server presumably materializes in memory, and fails.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org