Ok, so, when SAI has no feature gaps and you consider 2i to not be safe then what is preventing us from deprecating 2i as suggested? Just not enough production workloads / experience running that?
Jon mentioned the performance earlier (vector search) so when that is addressed / improved then we will deprecate 2i? That is how I understand that because if perf is good and feature gap is none then what else is missing to deprecate 2i? I am trying to somehow quantify what needs to be done / what needs to happen to say 2i is deprecated so we can do that and say that SAI is SAI without any beta status or similar. On Tue, Dec 10, 2024 at 3:31 PM Caleb Rackliffe <calebrackli...@gmail.com> wrote: > > I’m not convinced SAI has demonstrated a practical or theoretical > capability to fully replace secondary indexes anyway. So it would be very > premature to mark them deprecated. > > > If 2i indexes are to be marked as deprecated and SAI is beta, then what > is actually the index implementation we stand behind in the production? It > is like we are "abandoning" the former but the latter is not bullet-proof > yet. > > The table-based 2i implementation has never been safe to use, and I don't > think it ever will be, however we label it. (ex. CASSANDRA-18656, it's > on-disk bloat, post-streaming rebuilds, etc.) There is no reason it should > ever be more capable than SAI for any partition/token-restricted query > use-case, and I don't really see how there's any short-term path for any > local 2i implementation in C* to be efficient for anything else. There are > presently no feature gaps on the query side. > > Anyway, there are still a lot of things we can improve about SAI (and > things that already exist and are just waiting in the DS public fork)...I'm > just not sure what reasonable use case the old 2i will be able to serve > better. > > On Tue, Dec 10, 2024 at 5:41 AM Benedict <bened...@apache.org> wrote: > >> I’m not convinced SAI has demonstrated a practical or theoretical >> capability to fully replace secondary indexes anyway. So it would be very >> premature to mark them deprecated. >> >> On 10 Dec 2024, at 06:29, Štefan Miklošovič <smikloso...@apache.org> >> wrote: >> >> >> ... then we should NOT mark it to be deprecated. >> >> On Tue, Dec 10, 2024 at 12:27 PM Štefan Miklošovič < >> smikloso...@apache.org> wrote: >> >>> I have a hard time getting used to the "terminology" here. If 2i indexes >>> are to be marked as deprecated and SAI is beta, then what is actually the >>> index implementation we stand behind in the production? It is like we are >>> "abandoning" the former but the latter is not bullet-proof yet. The signal >>> it sends is that we don't have a non-deprecated bullet-proof index impl. >>> >>> Maybe it is just about the wording and people are just fine running >>> deprecated things knowing they are production-ready, what I am used to is >>> that if something is deprecated, then there is always a replacement which >>> is recommended. If there isn't a recommended replacement which can fully >>> superseed the current implementation then we should mark it to be >>> deprecated. >>> >>> I understand that you are trying to find some "common ground" / >>> expressing that we are moving towards SAI but I am not sure the wording is >>> entirely correct or we should be careful how we frame it. >>> >>> On Tue, Dec 10, 2024 at 12:01 PM Mick Semb Wever <m...@apache.org> wrote: >>> >>>> > A possibility with SAI is to mark it beta while also marking 2i as >>>> > deprecated (and leaving SASI as marked). This sends a clear signal >>>> > (imho) that SAI is the recommended solution forward but also being >>>> > honest about its maturity and QA. >>>> >>>> >>>> (and leaving SASI as marked *experimental*) >>>> >>>
