[
https://issues.apache.org/jira/browse/CASSANDRA-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17760523#comment-17760523
]
Jeremiah Jordan commented on CASSANDRA-18796:
---------------------------------------------
1024 is no comically high. You have that many with a 3 level LCS. I am again
-1 on having any kind of fail threshold by default. Those slow queries are not
causing any harm besides being slow, so I see no reason to fail them. The WARN
threshold is already there to tell the user thy their queries are slow. No
need to start failing all their queries when one more sstable shows up to go
from 1023 to 1024. This is why I am against a fail threshold, someone who is
doing this will have an app that is "working", possibly slowly, and then boom
they flush that file to go over the limit and everything falls over.
> Optionally fail when a non-partition-restricted query is issued against a
> storage-attached index with a backing table using LCS
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18796
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index, Feature/SAI, Local/Compaction/LCS
> Reporter: Caleb Rackliffe
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> With LCS, we will have potentially thousands of SSTables for a given user
> table. Storage-attached also means SSTable-attached, and searching thousands
> of attached indexes is not going to scale well at all locally, due to the
> sheer number of searches and amount of postings list merging involved. We
> should have a guardrail to prohibit this by default.
> Partition-restricted queries, the use-case SAI is broadly designed for,
> should be very efficient.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
