Re: [DISCUSS] Default Selection of 2i

[C. Scott Andreas]

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 lands, but for now the change in default seems valuable. Thoughts?