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 <https://issues.apache.org/jira/browse/CASSANDRA-19007>, which hopefully happens soon.
On Tue, Oct 1, 2024 at 9:23 PM Jon Haddad <j...@rustyrazorblade.com> wrote: > This also seems like an optimization. Why not go in 5.0? > > > On Tue, Oct 1, 2024 at 10:14 PM Jordan West <jorda...@gmail.com> 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 <calebrackli...@gmail.com> >> wrote: >> >>> Alrighty, with what looks like a fair amount of support, I'll declare >>> CASSANDRA-19968 <https://issues.apache.org/jira/browse/CASSANDRA-19968> >>> ready >>> for some preliminary review. >>> >>> On Tue, Oct 1, 2024 at 2:41 PM Caleb Rackliffe <calebrackli...@gmail.com> >>> wrote: >>> >>>> We did add CASSANDRA-18940 >>>> <https://issues.apache.org/jira/browse/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 PM Jeremiah Jordan < >>>> jeremiah.jor...@gmail.com> wrote: >>>> >>>>> 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 1:51:10 PM, Jon Haddad <j...@rustyrazorblade.com> >>>>> wrote: >>>>> >>>>>> 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 < >>>>>> calebrackli...@gmail.com> 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 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 this behavior. >>>>>>> >>>>>>> On Tue, Oct 1, 2024 at 12:43 PM Jeff Jirsa <jji...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > On Oct 1, 2024, at 10:28 AM, Caleb Rackliffe < >>>>>>>> calebrackli...@gmail.com> 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. This means that >>>>>>>> they >>>>>>>> bypass the digest read process that normal single-partition reads do. >>>>>>>> >>>>>>>> TIL. >>>>>>>> >>>>>>>> > >>>>>>>> > While I don't think this is something that we need to consider >>>>>>>> for 5.0, I would be very interested in the next major release being >>>>>>>> able to >>>>>>>> use proper single-partition reads for partition-restricted index >>>>>>>> queries, >>>>>>>> allowing them to take advantage of digest reads. (If single partition >>>>>>>> slice >>>>>>>> queries do it, why not index queries?) >>>>>>>> >>>>>>>> This seems like an obvious yes, so reverse the question - is there >>>>>>>> any reason why we WOULDNT want to do this? >>>>>>>> >>>>>>>> (Higher rate of mismatches requiring a second full read? Why would >>>>>>>> 2i be more likely?) >>>>>>>> >>>>>>>>
