[
https://issues.apache.org/jira/browse/IGNITE-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-8974:
-----------------------------------
Description:
At the moment vacuum process obtains cleanup version as the same way as
transactions do. It implies some unnecessary complications and even minor
performance drop due to calculation entire tx snapshot instead of just a
cleanup version number or sending unnsecessary tx end acks back to the
coordinator. Possible solutions are:
* Local caching cleanup version from the last obtained tx snapshot and use it
in vacuum process. But in this way not all outdated versions could be cleaned
(i.e. keys updated by this last tx).
* Implement a special method for calculating cleanup version on the
coordinator site and Request and Response messages for vacuum runned on
non-coordinator site.
was:
At the moment vacuum process obtains cleanup version as the same way as
transactions do. It implies some unnecessary complications and even minor
performance drop due to calculation entire tx snapshot instead of just a
cleanup version number or sending unnsecessary tx end acks back to the
coordinator. Possible solutions are:
* Local caching cleanup version from the last obtained tx snapshot and use it
in vacuum process. But in this way not all outdated versions could be cleaned
(i.e. keys updated by this last tx).
* Implement a special method for calculating cleanup version on the
coordinator site and Request and Response messages for vacuum runned on
non-coordinator side.
> MVCC TX: Vacuum cleanup version obtaining optimization.
> -------------------------------------------------------
>
> Key: IGNITE-8974
> URL: https://issues.apache.org/jira/browse/IGNITE-8974
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
> Reporter: Roman Kondakov
> Assignee: Roman Kondakov
> Priority: Major
> Labels: mvcc
>
> At the moment vacuum process obtains cleanup version as the same way as
> transactions do. It implies some unnecessary complications and even minor
> performance drop due to calculation entire tx snapshot instead of just a
> cleanup version number or sending unnsecessary tx end acks back to the
> coordinator. Possible solutions are:
> * Local caching cleanup version from the last obtained tx snapshot and use
> it in vacuum process. But in this way not all outdated versions could be
> cleaned (i.e. keys updated by this last tx).
> * Implement a special method for calculating cleanup version on the
> coordinator site and Request and Response messages for vacuum runned on
> non-coordinator site.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
