Andrey, thanks for firing this !
Sasha it`s unclear for me « These part consists of two processes: statistics
collection process itself and acquiring statistics by the client. »:
* I agree that in both cases local statistics are useless.
May be we need more informative use cases for such statistics usage ? Can
someone append additional columns (possible not presented in index) statistics?
* Client — can you unfold this term ? If this means — ignite client node ?
Does sql best plan is chosen in request starter node ? If so — what about this
client with limited cpu here?
* « If there are no statistics in all of them - client will choose random »
— not random but affinity concerted isn`t it ?
* « After getting statistics client will cache it and server node it to renew
statistics from same node. » I don`t understand this approach, can you
clarify it plz ?
* Whats the storage mechanism for client node statistics?
* Can we use thin client without discs in such cases?
thanks !
>:
>
>Follow up
>
>Igniters,
>
>is there any comment to this IEP?
>
>JFYI, IEP is renamed and placed here [1]
>
>[1]
>https://cwiki.apache.org/confluence/display/IGNITE/IEP-58%3A+Statistics+for+SQL+query+optimization
>
>On Thu, Sep 24, 2020 at 2:30 PM Sasha Belyak < rtsfo...@gmail.com > wrote:
>>
>> Igniters,
>> I'e prepared an IEP [1], please review and let me know what you think.
>>
>> In particular, I'd like to discuss the new subsystem to collect statistics
>> to optimize sql queries execution.
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-58+Statistics
