Tossing out an idea without any knowledge of implementation details - could we use the SAI index when a partition key is provided, and legacy when none is?
On Thu, Feb 6, 2025 at 1:59 PM Benedict <bened...@apache.org> wrote: > Oof, if nothing else it sounds like a bug that we prefer an unbuilt index > over a built one when there’s a choice. > > It also sounds like a bug for SAI to self report as the best index without > any consideration, but perhaps that is harder to address. > > > On 6 Feb 2025, at 21:15, C. Scott Andreas <sc...@paradoxica.net> wrote: > > Preference for a yaml property and MBean. Briefly: > > – All other secondary index config is defined in yaml. > – System properties are more cumbersome to manage in that they’re less > structured and commingle JVM configuration with database configuration. > – We need an MBean hot property so users can flip to their desired index > preference once it’s built without restarting the database. > – When hot props are tweaked, it’s easy to follow by updating yaml on > disk; but system props set as launch args will disagree in ps output vs. > the config in effect at runtime. > > I also want to highlight the user pain here for the current default. If a > user has a 2i index and decides to create an SAI index on the same field, > their app will immediately break because the SAI index takes precedence - > even if it’s not yet built and unready for querying. > > Defaulting to SAI in the presence of both index types triggers an outage > when new users adopt the feature, which is an awful first taste - and users > excited about SAI are most likely to want to transition the indexes they > already have. > > However I’m sympathetic to the fact that for those who have made the leap, > it would be undesirable to switch them back to 2i so changing the default > in trunk seems fine. > > - Scott > > — > Mobile > > On Feb 6, 2025, at 11:42 AM, Caleb Rackliffe <calebrackli...@gmail.com> > wrote: > > > System property works for me, even if I have to leave the default alone in > 5.0.x > > On Thu, Feb 6, 2025 at 1:34 PM Jeremiah Jordan <jeremiah.jor...@gmail.com> > wrote: > >> Rather than changing the default, I would be +1 to making a system >> property so that an operator who knows what they are doing could change >> it. A little hesitant of just changing it outright in a patch release. >> >> >> >> On Feb 6, 2025 at 1:10:28 PM, Caleb Rackliffe <calebrackli...@gmail.com> >> wrote: >> >>> Hey everyone! >>> >>> I'll keep this short. SASI and later SAI, in lieu of anything resembling >>> a query planner, have always just greedily returned a min long from >>> Index#getEstimatedResultRows(), thereby stealing the right to be used to >>> execute the query even when a legacy 2i is present on the relevant columns. >>> If we have a user that needs to migrate away from a legacy 2i, this seems >>> like the exact opposite of what we want to do by default. I want to propose >>> that we invert this behavior, and have legacy 2i continue to serve queries >>> instead of new SAI indexes by default until they are dropped. >>> >>> Note that we'll have more options around this when CASSANDRA-18112 >>> <https://issues.apache.org/jira/browse/CASSANDRA-18112> lands, but for >>> now the change in default seems valuable. >>> >>> Thoughts? >>> >>
