[
https://issues.apache.org/jira/browse/IGNITE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305147#comment-16305147
]
Roman Kondakov commented on IGNITE-6022:
----------------------------------------
[~vozerov], my comments:
1) I agree. I'll add this test.
2) Concerning flushing all batches on duplicates found - I agree it's not
efficient, I'll change this behavior into flushing only the affected batch.
Concerning replacing a {{Map<Integer, Integer> cntPerRow}} with an array. I
think it is not a good idea because we do not know the total size of the rows
we need to update on {{DmlBatchSender}} creation stage. We have only cursor
which allows to iterate over these rows. So, we have to manage the array size
manually and extend it on demand. But it is possible to replace the {{Map}}
with an {{ArrayList}}. I'm not sure it is much more efficient and easier to
implement than a map, but I agree that if we have a range of integer keys from
{{0}} to {{N}} it better to use array-like structures than map. I'll replace
map with an {{ArrayList}}.
3) I'll remove this method.
4) I agree. I'll add tests with various scenarios in {{JdbcThinBatchSelfTest}}.
Or should I add these tests not only for thin driver, but also for all Ignite
JDBC driver types?
> SQL: add native batch execution support for DML statements
> ----------------------------------------------------------
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
> Issue Type: Task
> Components: sql
> Affects Versions: 2.1
> Reporter: Vladimir Ozerov
> Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases
> number of network hops. However, we do not have any batch execution support
> on the server side. It means that for batch of N similar statements, every
> statement will go through the whole execution chain - parsing, splitting,
> communication with servers. And while parsing and splitting might be avoided
> with help of statement cache, the most heavy part - network communication -
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse
> the same request multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
