[
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)
