[
https://issues.apache.org/jira/browse/KUDU-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723602#comment-16723602
]
Brock Noland commented on KUDU-1563:
------------------------------------
[~adar]
> I am nervous about inflating the memory consumption of each operation, and
> I'm not sure how to preserve backwards compatibility in the C++ client's
> non-PIMPL'ed KuduWriteOperation class. If you can address both of these
> concerns, I'd be open to per-operation configuration.
>From a memory perspective, I think this can be implemented as a bitmask on an
>integer which would consume little memory on a per-operation basis.
I am not sure how to solve the PIMPL'ed issue either but I am happy to
investigate. What would be implications be if we could not do this in a
backwards compatible way? FWIW - I am sure someone outside Impala is using the
C++ client, but in my customer base of 25+ Kudu users, we don't have a single
one. Thus my gut tells me it's a very small number of users.
> Add support for INSERT IGNORE
> -----------------------------
>
> Key: KUDU-1563
> URL: https://issues.apache.org/jira/browse/KUDU-1563
> Project: Kudu
> Issue Type: New Feature
> Reporter: Dan Burkert
> Assignee: Brock Noland
> Priority: Major
> Labels: newbie
>
> The Java client currently has an [option to ignore duplicate row key errors|
> https://kudu.apache.org/apidocs/org/kududb/client/AsyncKuduSession.html#setIgnoreAllDuplicateRows-boolean-],
> which is implemented by filtering the errors on the client side. If we are
> going to continue to support this feature (and the consensus seems to be that
> we probably should), we should promote it to a first class operation type
> that is handled on the server side. This would have a modest perf.
> improvement since less errors are returned, and it would allow INSERT IGNORE
> ops to be mixed in the same batch as other INSERT, DELETE, UPSERT, etc. ops.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
