[
https://issues.apache.org/jira/browse/CASSANDRA-18796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759101#comment-17759101
]
Jeremiah Jordan commented on CASSANDRA-18796:
---------------------------------------------
16/128 Seems very low to me. Do you have benchmarks to prove out where the
number of sstables searched starts being problematic? Also from my
understanding SAI Segments the index data in the files. So how is 128 small
sstables being searched that different from 1 giant sstables that has 128 index
segments?
Not saying this isn't something we want to warn people about. But I really
think the warning is the main thing, not failing queries necessarily. The
queries will timeout/be slow if the number is excessive for someone's database,
and we should make sure to drive the user with the possible reason why in a
warning and in metrics.
> 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
