Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

It's certainly an improvement/optimization, so I wouldn't object to it being in 5.0.x. I have no plans to touch the outstanding ways ALLOW FILTERING is broken until I get to CASSANDRA-19007 , which hopefully happens soon. On Tue, Oct 1, 2024 a

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

This also seems like an optimization. Why not go in 5.0? On Tue, Oct 1, 2024 at 10:14 PM Jordan West wrote: > Agreed this would absolutely be a win. Dont see need for a flag either. > > On Tue, Oct 1, 2024 at 1:31 PM Caleb Rackliffe > wrote: > >> Alrighty, with what looks like a fair amount of

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

Agreed this would absolutely be a win. Dont see need for a flag either. On Tue, Oct 1, 2024 at 1:31 PM Caleb Rackliffe wrote: > Alrighty, with what looks like a fair amount of support, I'll declare > CASSANDRA-19968 ready > for some prelimi

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

Alrighty, with what looks like a fair amount of support, I'll declare CASSANDRA-19968 ready for some preliminary review. On Tue, Oct 1, 2024 at 2:41 PM Caleb Rackliffe wrote: > We did add CASSANDRA-18940 >

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

Did we add new metrics for index queries? The only issue I see is that this change will mix index queries into the regular read metrics, where before they were in the range metrics, so maybe some changes to metrics should go with it. But I think this is a good change over all. On Oct 1, 2024 at

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

We did add CASSANDRA-18940 to make sure local SAI post-filtering reads got picked up somewhere, but you're right that StorageProxy#readRegular() would start recording some index queries in the normal read metrics. On Tue, Oct 1, 2024 at 2:11 

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

This seems like it's strictly a win. Doesn't sound to me like a flag is needed. On Tue, Oct 1, 2024 at 2:44 PM Caleb Rackliffe wrote: > > (Higher rate of mismatches requiring a second full read? Why would 2i be > more likely?) > > Right, I don't see any reason they should be more likely to actu

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

> (Higher rate of mismatches requiring a second full read? Why would 2i be more likely?) Right, I don't see any reason they should be more likely to actuate read-repair than slice queries are today... Didn't mention this above, but I'd obviously be open to having a system property that switches t

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

> On Oct 1, 2024, at 10:28 AM, Caleb Rackliffe wrote: > > Hello fellow secondary index enjoyers! > > If you're familiar with index queries, you probably know that they are > treated as range reads no matter what. This is true even if the user query > restricts results to a single partition.

[DISCUSS] Secondary Indexes and Single-Partition Reads

Hello fellow secondary index enjoyers! If you're familiar with index queries, you probably know that they are treated as range reads no matter what. This is true even if the user query restricts results to a single partition. This means that they bypass the digest read process that normal single-p