phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3612) Make tracking of max allowed number of mutations bytes based instead of row based
Date Wed, 31 May 2017 03:46:04 GMT

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

Thomas D'Silva commented on PHOENIX-3612:
-----------------------------------------

[~jamestaylor]


We currently check the size of the {{Map<TableRef, Map<ImmutableBytesPtr,RowMutationState>>
mutations}} map in the MutationState constructor and throw an exception if it exceeds the
 {{QueryServices.MAX_MUTATION_SIZE_ATTRIB}}  limit, so we don't have the {{List<Mutation>}}
at this point, should we estimate the size based on {{RowMutationState}} which has the column
values ? 

Should I keep the existing config and add a new one to maintain b/w compatibility? (and use
the lower of the byte based and row count limit)





> Make tracking of max allowed number of mutations bytes based instead of row based
> ---------------------------------------------------------------------------------
>
>                 Key: PHOENIX-3612
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3612
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>             Fix For: 4.11.0
>
>
> Some remaining work related to PHOENIX-541 to track the byte-size of all mutations being
buffered instead of the number of rows:
> - Make similar changes QueryServices.MAX_MUTATION_SIZE_ATTRIB - making it byte-based
instead of row-count-based. Usage of this config parameter would be isolated to MutationState,
I believe. We should be able to come up with an accurate size based on the underlying Mutation
and/or Delete info we store in PRowImpl.
> - Have a reasonable (smaller) default for the new QueryServices.MAX_MUTATION_SIZE_BYTES_ATTRIB
> This is essentially a guard on the memory usage. It could potentially leverage our MemoryManager.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message