[
https://issues.apache.org/jira/browse/CASSANDRA-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14949521#comment-14949521
]
Jon Haddad commented on CASSANDRA-10489:
----------------------------------------
{quote}
I would like for us to consider this operation for indexed fields and
non-indexed fields as separate features, possibly putting the non-indexed
version behind a warning or such.
{quote}
Assuming they'd be different code paths it would make sense to consider them
separate features.
{quote}
possibly putting the non-indexed version behind a warning or such. I'm sure
some will absolutely try to sort 10^9 unindexed items with limit 10. At least
they should know that it has a completely different op cost.
{quote}
I'd be a little concerned we'd be generating a lot of noise if we warn every
time a user sorts on a non indexed field. I'm giving myself 100% chance of
doing this on partitions with 10s to hundreds of rows, and seeing warnings
every time would render them useless. I think a threshold makes more sense
here, similar to tombstone_warn_threshold, and maybe even a failure similar to
tombstone_failure_threshold.
> arbitrary order by on partitions
> --------------------------------
>
> Key: CASSANDRA-10489
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10489
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jon Haddad
> Priority: Minor
>
> We've got aggregations, we might as well allow sorting rows within a
> partition on arbitrary fields. Currently the advice is "do it client side",
> but when combined with a LIMIT clause it makes sense do this server side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
