[ https://issues.apache.org/jira/browse/FLINK-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16656424#comment-16656424 ]
ASF GitHub Bot commented on FLINK-10095: ---------------------------------------- Aitozi commented on issue #6510: [FLINK-10095][State TTL] Swap serialization order in TTL value: first timestamp then user value URL: https://github.com/apache/flink/pull/6510#issuecomment-431280282 Hi, @azagrebin @StefanRRichter I mentioned an question at this issue page, but got no response, so i ask here again >If we serialize uservalue first, we can also work directly with serialized value by skipping looking into the rest of 8 bytes at the end. So I think do not need to change the order of serialization, do you think so? And so we can also optimize when delete the expired data in liststate. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change the serialisation order in TTL value wrapper > --------------------------------------------------- > > Key: FLINK-10095 > URL: https://issues.apache.org/jira/browse/FLINK-10095 > Project: Flink > Issue Type: Improvement > Components: State Backends, Checkpointing > Reporter: Andrey Zagrebin > Assignee: Andrey Zagrebin > Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > > The first implementation of TTL value wrapper has the following serialisation > order: first user value, then last modification timestamp. > This was planned for potential optimisation where we could peek at the last > bytes of last element of list to check whether the whole list expired or not. > After careful consideration, it is not the frequent case and the list is > handled per entry mostly. > Having the fixed part (the timestamp) at the beginning looks more promising > in future as we can skip looking into the rest of bytes if needed when > working directly with serialised value. > This issue suggests to change the serialisation order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)