You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Igor Seliverstov (JIRA)" <ji...@apache.org> on 2019/02/27 14:23:00 UTC
[jira] [Updated] (IGNITE-10729) MVCC TX: Improvements.
[ https://issues.apache.org/jira/browse/IGNITE-10729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Seliverstov updated IGNITE-10729:
--------------------------------------
Description:
1) vacuum doesn't have change set, this means it travers all data to find invisible entries; hanse it breaks read statistics and make all data set "hot" - we should travers data entries instead, and only those entries, which was updated (linked to newer versions), moreover, vacuum should travers only those data pages, which were updated after last successful vacuum (at least one entry on the data page was linked to a never one)
2) vacuum travers over partitions instead of data entries, so, there possible some races like: reader checks an entry; updater removes this entry from partition; vacuum doesn't see the entry and clean TxLog -> reader cannot check the entry state with TxLog and gets an exception. This race prevents an optimization when all entries, older than last successful vacuum version, are considered as COMMITTED (see previous suggestion)
was:
Currently there are several problems:
1) vacuum doesn't have change set, this means it travers all data to find invisible entries; hanse it breaks read statistics and make all data set "hot" - we should travers data entries instead, and only those entries, which was updated (linked to newer versions), moreover, vacuum should travers only those data pages, which were updated after last successful vacuum (at least one entry on the data page was linked to a never one)
2) vacuum travers over partitions instead of data entries, so, there possible some races like: reader checks an entry; updater removes this entry from partition; vacuum doesn't see the entry and clean TxLog -> reader cannot check the entry state with TxLog and gets an exception. This race prevents an optimization when all entries, older than last successful vacuum version, are considered as COMMITTED (see previous suggestion)
3) all entry versions are placed in BTrees, so, we cannot do updates like PG - just adding a new version and linking the old one to it. Having only one unversioned item per row in all indexes making possible fast invoke operations on such indexes in MVCC mode. Also it let us not to update all indexes on each update operation (partition index isn't updated at all, only SQL indexes, built over changed fields need to be updated) - this dramatically reduces write operations, hence it reduces amount of pages to be "checkpointed" and reduces checkpoint mark phase.
> MVCC TX: Improvements.
> ----------------------
>
> Key: IGNITE-10729
> URL: https://issues.apache.org/jira/browse/IGNITE-10729
> Project: Ignite
> Issue Type: Improvement
> Components: mvcc
> Reporter: Igor Seliverstov
> Priority: Major
>
> 1) vacuum doesn't have change set, this means it travers all data to find invisible entries; hanse it breaks read statistics and make all data set "hot" - we should travers data entries instead, and only those entries, which was updated (linked to newer versions), moreover, vacuum should travers only those data pages, which were updated after last successful vacuum (at least one entry on the data page was linked to a never one)
> 2) vacuum travers over partitions instead of data entries, so, there possible some races like: reader checks an entry; updater removes this entry from partition; vacuum doesn't see the entry and clean TxLog -> reader cannot check the entry state with TxLog and gets an exception. This race prevents an optimization when all entries, older than last successful vacuum version, are considered as COMMITTED (see previous suggestion)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)