[
https://issues.apache.org/jira/browse/IGNITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191253#comment-16191253
]
Vladimir Ozerov commented on IGNITE-6024:
-----------------------------------------
[~skalashnikov], I thought about the whole idea a bit more, and here are my
points:
1) This mode is rather dangerous. First, it doesn't support failover, previous
implementation is less susceptible to exception in case of topology change.
Second, what if our heuristic about whether such update is possible is wrong in
some specific case we are not aware of? In this case user will be blocked with
not workaround. I think we'd better to disable this feature by default and
control it through a property. E.g. {{SqlFieldsQuery.updateOnServer}}. We will
treat it as "experimental" for some time, and if all is OK - make it default in
the next release.
2) We need more tests with different queries. E.g. with GROUP BY, joins,
DISTINCT, etc.. We need to ensure that final result is correct for both
{{updateOnServer=true}} and {{updateOnServer=false}} modes.
> SQL: execute DML statements on the server when possible
> -------------------------------------------------------
>
> Key: IGNITE-6024
> URL: https://issues.apache.org/jira/browse/IGNITE-6024
> Project: Ignite
> Issue Type: Task
> Components: sql
> Affects Versions: 2.1
> Reporter: Vladimir Ozerov
> Assignee: Sergey Kalashnikov
> Labels: important, performance
> Fix For: 2.3
>
>
> Currently we execute DML statements as follows:
> 1) Get query result set to the client
> 2) Construct entry processors and send them to servers in batches
> This approach is inefficient as it causes a lot of unnecessary network
> communication Instead, we should execute DML statements directly on server
> nodes when it is possible.
> Implementation considerations:
> 1) Determine set of queries which could be processed in this way. E.g.,
> {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of
> question - they must go through the client anyway. Probably
> {{skipMergeTable}} flag is a good starting point (good, not precise!)
> 2) Send request to every server and execute local DML right there
> 3) No failover support at the moment - throw "partial update" exception if
> topology is unstable
> 4) Handle partition reservation carefully
> 5) Transactions: we still have single coordinator - this is a client. When
> MVCC and TX SQL is ready, client will assign proper counters to server
> requests.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
