I think we can handle manual index selection controls independently of the
larger problem of query optimization.
Once I have time to get to know CEP-39 and the DS approach a little better,
I can open another thread here to start talking about those in the context
of the problems we need to solve.
If we can also build CBO capabilities for Cassandra in the future, it will
be of great help to Cassandra in expanding its ability to analyze big data.
If CEP-39 can be adopted, is it possible to divide the big task to some
sub-tasks and combine the power of the community to jointly advance this
mat
I am personally -1 against the approach taken by DS for optimizing SAI
queries. I consider it as a quick fix rather than a proper long term
solution.
The issue with this approach is that it splits the optimisation logic of
queries. With one part of the optimization happening on the coordinator
whil
Wrong typing, it is DML not DDL ~~~😅
guo Maxwell 于2024年12月23日周一 11:56写道：
> Thanks Caleb for bringing it up.
>
> When I opened this issue, I originally wanted to propose the following
> syntax:
> 1、When we want to force the selection of certain indexes:
> SELECT ...USE INDEX (ks.idx1, ks.idx2
Thanks Caleb for bringing it up.
When I opened this issue, I originally wanted to propose the following
syntax:
1、When we want to force the selection of certain indexes:
SELECT ...USE INDEX (ks.idx1, ks.idx2) ... FROM ...WHERE ...
or
SELECT .../*+ USE INDEX (ks.idx1, ks.idx2)*/ ... FROM
Naming is hard but to me providing what Caleb mentioned through something
like WITH OPTIONS sounds reasonable. Thanks for bringing it up.
On Sat, 21 Dec 2024 at 2:46, Joel Shepherd wrote:
> WITH INDEX (or something equivalent) seems really useful.
>
> Less opinionated on the specific syntax, but
WITH INDEX (or something equivalent) seems really useful.
Less opinionated on the specific syntax, but I think there is a lot of
value in the form of predictable, controllable performance, in giving
developers more direct control over query execution, whether that's
index selection or even low
>
> On Fri, Dec 20, 2024 at 5:36 PM Caleb Rackliffe
> wrote:
>
>> You mean like to control the tokenization/analysis of query terms?
>>
>
Yes. Elastic for example lets you specify the query time analyzer in the
query, over riding what is specified at the index level.
https://www.elastic.co/guide
You mean like to control the tokenization/analysis of query terms?
On Fri, Dec 20, 2024 at 4:38 PM Jeremiah Jordan
wrote:
> Rather than WITH INDEX/WITHOUT INDEX what about WITH OPTIONS {}. If we
> move into allowing analysis/tokenization on indexed items, then a more
> general WITH OPTIONS woul
So that would look something like...
SELECT ... FROM ... WHERE ... WITH OPTIONS = { 'exclude_indexes' :
[, ] }
On Fri, Dec 20, 2024 at 5:36 PM Caleb Rackliffe
wrote:
> You mean like to control the tokenization/analysis of query terms?
>
> On Fri, Dec 20, 2024 at 4:38 PM Jeremiah Jordan
> wrote
Rather than WITH INDEX/WITHOUT INDEX what about WITH OPTIONS {}. If we
move into allowing analysis/tokenization on indexed items, then a more
general WITH OPTIONS would be useful for that too. That would let us add
any other new options to a SELECT without needing to modify the grammar
further.
Some of your are probably familiar with work in the DS fork to improve the
selection of indexes for SAI queries in
https://github.com/datastax/cassandra/commit/eeb33dd62b9b74ecf818a263fd73dbe6714b0df0#diff-2830028723b7f4af5ec7450fae2c206aeefa5a2c3455eff6f4a0734a85cb5424
.
While I'm eagerly anticip
12 matches
Mail list logo
