[ 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)