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?) >>> >>>
