[
https://issues.apache.org/jira/browse/CASSANDRA-11556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237281#comment-15237281
]
Alex Petrov commented on CASSANDRA-11556:
-----------------------------------------
I've found the source of the problem: it's post-query ordering clause. I've
written a little patch
[here|https://github.com/ifesdjeen/cassandra/tree/11556-trunk], although I can
say that, for example, queries like {{SELECT COUNT(*) FROM tbl PER PARTITION
LIMIT 5}} would return unexpected amount of results, since aggregate queries do
not respect limits at the moment.
Do we want to support these queries, disallow them (this would be quite simple,
just checking for {{perPartitionLimit == null && selection.isAggregate()}}?
> PER PARTITION LIMIT does not work properly for multi-partition query with
> ORDER BY
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-11556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11556
> Project: Cassandra
> Issue Type: Bug
> Reporter: Benjamin Lerer
> Assignee: Alex Petrov
> Fix For: 3.6
>
>
> Multi-partition queries with {{PER PARTITION LIMIT}} with {{ORDER BY}} do not
> respect the {{PER PARTITION LIMIT}}.
> The problem can be reproduced with the following unit test:
> {code}
> @Test
> public void testPerPartitionLimitWithMultiPartitionQueryAndOrderBy()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, c int, PRIMARY KEY (a,
> b))");
> for (int i = 0; i < 5; i++)
> {
> for (int j = 0; j < 5; j++)
> {
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)", i, j, j);
> }
> }
> assertRows(execute("SELECT * FROM %s WHERE a IN (2, 3) ORDER BY b
> DESC PER PARTITION LIMIT ?", 2),
> row(2, 4, 4),
> row(3, 4, 4),
> row(2, 3, 3),
> row(3, 3, 3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
