I don’t think there’s going to be any real support for doing it in 5.0 anyway at this point.On May 12, 2023, at 1:48 PM, Benedict wrote:Given we have no data in front of us to make a decision regarding switching defaults, I don’t think it is suitable to include that option in this poll. In fact,
Given we have no data in front of us to make a decision regarding switching defaults, I don’t think it is suitable to include that option in this poll. In fact, until we have sufficient data to discuss that I’m going to put a hard veto on that on technical grounds.On 12 May 2023, at 19:41, Caleb Ra
> [POLL] Centralize existing syntax or create new syntax?
1.) CREATE INDEX ... USING WITH OPTIONS...
> [POLL] Should there be a default? (YES/NO)
YES
> [POLL] What do do with the default?
3.) YAML config to override default index (legacy 2i remains the default)
DESCRIBE should always s
...and to clarify, answers should be what you'd like to see for 5.0
specifically
On Fri, May 12, 2023 at 1:36 PM Caleb Rackliffe
wrote:
> [POLL] Centralize existing syntax or create new syntax?
>
> 1.) CREATE INDEX ... USING WITH OPTIONS...
> 2.) CREATE LOCAL INDEX ... USING ... WITH OPTION
[POLL] Centralize existing syntax or create new syntax?
1.) CREATE INDEX ... USING WITH OPTIONS...
2.) CREATE LOCAL INDEX ... USING ... WITH OPTIONS... (same as 1, but adds
LOCAL keyword for clarity and separation from future GLOBAL indexes)
(In both cases, we deprecate w/ client warnings C
But then we have to reconsider the existing syntax, or do we want LOCAL to be the default?We should be planning our language evolution along with our feature evolution.On 12 May 2023, at 19:28, Caleb Rackliffe wrote:If at some point in the glorious future we have global indexes, I'm sure we can a
If at some point in the glorious future we have global indexes, I'm sure we
can add GLOBAL to the syntax...sry, working on an ugly poll...
On Fri, May 12, 2023 at 1:24 PM Benedict wrote:
> If folk should be reading up on the index type, doesn’t that conflict with
> your support of a default?
>
>
If folk should be reading up on the index type, doesn’t that conflict with your
support of a default?
Should there be different global and local defaults, once we have global
indexes, or should we always default to a local index? Or a global one?
> On 12 May 2023, at 18:39, Mick Semb Wever wro
The vote passed with 3 binding +1's and 0 binding -1's.
https://lists.apache.org/thread/39s345w5fv2r4z7p0jjslc2vf6rqdjk1
>
>
> Given it seems most DBs have a default index (see Postgres, etc.), I tend
> to lean toward having one, but that's me...
>
I'm for it too. Would be nice to enforce the setting is globally uniform
to avoid the per-node problem. Or add a keyspace option.
For users replaying <5 DDLs this woul
There remains the question of what the new syntax is - whether it augments CREATE INDEX to replace CREATE CUSTOM INDEX or if we introduce new syntax because we think it’s clearer.I can accept settling for modifying CREATE INDEX … USING, but I maintain that CREATE LOCAL INDEX is betterOn 12 May 202
Even if we don't want to allow a default, we can keep the same CREATE INDEX
syntax in place, and have a guardrail forcing (or not) the selection of an
implementation, right? This would be no worse than the YAML option we
already have for enabling 2i creation as a whole.
On Fri, May 12, 2023 at 12:
I’m not convinced a default index makes any sense, no. The trade-offs in a distributed setting are much more pronounced.Indexes in a local-only RDBMS are much simpler affairs; the trade offs are much more subtle than here. On 12 May 2023, at 18:24, Caleb Rackliffe wrote:> Now, giving this thread,
> Now, giving this thread, there is pushback for a config to allow default
impl to change… but there is 0 pushback for new syntax to make this
explicit…. So maybe we should [POLL] for what syntax people want?
I think the essential question is whether we want the concept of a default
index. If we d
I still prefer introducing CREATE LOCAL INDEX, to help users understand the semantics of the index they’re creating.I think it will in future potentially be quite confusing to be able to create global and local indexes using the same DDL statement.But, depending on appetite, that could plausibly be
> I really dislike the idea of the same CQL doing different things based upon a
> per-node configuration.
> I agree with Brandon that changing CQL behaviour like this based on node
> config is really not ideal.
I am cool adding such a config, and also cool keeping CREATE INDEX disabled by
def
So the weakest version of the plan that actually accomplishes something
useful for 5.0:
1.) Just leave the CREATE INDEX default alone for now. Hard switch the
default after 5.0.
2.) Add USING...WITH... support to CREATE INDEX, so we don't have to go to
market using CREATE CUSTOM INDEX, which feels
I don't want to cut over for 5.0 either way. I was more contrasting a
configurable cutover in 5.0 vs. a hard cutover later.
On Fri, May 12, 2023 at 12:09 PM Benedict wrote:
> If the performance characteristics are as clear cut as you think, then
> maybe it will be an easy decision once the evide
If the performance characteristics are as clear cut as you think, then maybe it will be an easy decision once the evidence is available for everyone to consider?If not, then we probably can’t do the hard cutover and so the answer is still pretty simple? On 12 May 2023, at 18:04, Caleb Rackliffe wr
I don't particularly like the YAML solution either, but absent that, we're
back to fighting about whether we introduce entirely new syntax or hard cut
over to SAI at some point.
We already have per-node configuration in the YAML that determines whether
or not we can create a 2i at all, right?
Wha
A table is not a local concept at all, it has a global primary index - that’s the core idea of Cassandra.I agree with Brandon that changing CQL behaviour like this based on node config is really not ideal. New syntax is by far the simplest and safest solution to this IMO. It doesn’t have to use the
On Fri, May 12, 2023 at 11:29 AM Caleb Rackliffe
wrote:
>
> Okay, so the proposal for 5.0...
>
> 1.) Add a YAML option that specifies a default implementation for CREATE
> INDEX, and make this the legacy 2i for now. No existing DDL breaks. We don't
> have to commit to the absolute superiority of
...and if we decide before the 5.0 release that we have enough information
to change the default (#1), we can change it in a matter of minutes.
On Fri, May 12, 2023 at 11:28 AM Caleb Rackliffe
wrote:
> We don't need to know everything about SAI's performance profile to plan
> and execute some sm
We don't need to know everything about SAI's performance profile to plan
and execute some small, reasonable things now for 5.0. I'm going to try to
summarize the least controversial package of ideas from the discussion
above. I've left out creating any new syntax. For example, I think CREATE
LOCAL
+1 (nb)
On Fri, 12 May 2023 at 14:05, Doug Rohrer wrote:
> +1 (nb)
>
> > On May 8, 2023, at 4:52 AM, Piotr Kołaczkowski
> wrote:
> >
> > Let's vote.
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
> >
> > Piotr Kołaczkowski
> > e. pkola...@datastax.com
if we didn't have copious amounts of (not all public, I know, working on it) evidenceIf that’s the assumption on which this proposal is based, let’s discuss the evidence base first, as given the fundamentally different way they work (almost diametrically opposite), I would want to see a very high q
> This creates huge headaches for everyone successfully using 2i today
though, and SAI *is not* guaranteed to perform as well or better - it has a
very different performance profile.
We wouldn't have even advanced it to this point if we didn't have copious
amounts of (not all public, I know, worki
+1 (nb)
> On May 8, 2023, at 4:52 AM, Piotr Kołaczkowski wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
This.
I would also consider adding CREATE LEGACY INDEX syntax as an alias for today’s
CREATE INDEX, the latter to be deprecated and (in very distant future) removed.
> On 12 May 2023, at 13:14, Benedict wrote:
>
> This creates huge headaches for everyone successfully using 2i today though,
>
This creates huge headaches for everyone successfully using 2i today though, and SAI *is not* guaranteed to perform as well or better - it has a very different performance profile.I think we should deprecate CREATE INDEX, and introduce new syntax CREATE LOCAL INDEX to make clear that this is not a
On Thu, 11 May 2023 at 05:27, Patrick McFadin wrote:
> Having pulled a lot of developers out of the 2i fire,
>
Yes. I'm keen not to leave 2i as the default once SAI lands. Otherwise I
agree with the deprecated first principle, but 2i is just too problematic.
Just having no default in 5.0, forc
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
Checked
- signing correct
- checksums are correct
- source art
32 matches
Mail list logo
