Thanks for details!
2021-12-13 11:14 GMT+03:00, Maksim Timonin :
> Hi, Ivan!
>
>> Does IndexQuery has separate codebase? Does it share some code with
> ScanQuery
>
> Yes, IndexQuery mostly shares processing with ScanQuery:
> requests/responses, a remote filter. Reducer (merge of query results) on
Hi, Ivan!
> Does IndexQuery has separate codebase? Does it share some code with
ScanQuery
Yes, IndexQuery mostly shares processing with ScanQuery:
requests/responses, a remote filter. Reducer (merge of query results) on an
initiator node has its own implementation for IndexQuery (MergeSort), but
> Then, if there are no objections, the short-term plan is:
Sounds ok for me.
> AFAIR Scan and SQL queries implementations are totally different. Could you
> tell me how Index queries fit there?
I suppose my questions was misleading. Actually I would like to know
how code is organized today. AF
Hi!
> Existing users may already have some logic in place to handle
inconsistencies
Pavel, I'm not aware of such users but your comment makes sense. So, I' OK
with adding an option for ScanQuery. Naming of the option is debatable. The
name "reservePartitions" looks good, but we actually already r
Actually I brought a point about using SQL queries instead of scan
queries because I worry about inconsistency between different
implementations. AFAIR Scan and SQL queries implementations are
totally different. Could you tell me how Index queries fit there?
My general ideas are as follows:
1. In
IndexQuery is experimental, so we can indeed make it reserve partitions by
default. No objections here.
But with ScanQuery, I think it's better to add a "reservePartitions"
property so that default behavior is not affected.
Existing users may already have some logic in place to handle
inconsistenc
Hi, Ivan, Pavel! Thanks for your responses.
> But is there a real need/benefit from using scan queries over primitive
SQL queries today
In addition to Pavel's response, I'd like to add about IndexQuery. This
query is in experimental status, but it shows great performance and beats
SQL for *some*
Agree with Ivan regarding compatibility.
Partition reservation should be opt-in if we decide to proceed.
> is there a real need/benefit from using
> scan queries over primitive SQL queries today
SQL requires additional configuration (QueryEntity) and involves memory and
CPU overhead to maintain t
Hi Maksim,
Thank you for looking into this. While fixing wrong/surprising
behavior is very important, I also have some concerns, let's say, from
different angle of view:
1. From a first glance it seems that similar behavior of scan and SQL
queries is a good idea. But is there a real need/benefit f
