[ 
https://issues.apache.org/jira/browse/KUDU-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505399#comment-15505399
 ] 

Brock Noland commented on KUDU-1563:
------------------------------------

Hi,

With the upsert patch, this change becomes pretty easy. The only open question 
I have right now is which metrics to track. I see a few options:

# fold these into inserts
# track separately counting only successful inserts
# track ignored and successful insert ignores separately

Looks like the upsert patch went with 2. It doesn't track upserts which were 
inserts or updates separately. Does that seem sufficient? 

I could make the case for tracking them separately, but I guess II'd feel that 
same argument would apply to upserts as well.

> INSERT IGNORE operation type
> ----------------------------
>
>                 Key: KUDU-1563
>                 URL: https://issues.apache.org/jira/browse/KUDU-1563
>             Project: Kudu
>          Issue Type: New Feature
>            Reporter: Dan Burkert
>            Assignee: Brock Noland
>              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
(v6.3.4#6332)

Reply via email to