[
https://issues.apache.org/jira/browse/IGNITE-26998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-26998:
-----------------------------------
Description:
What we do currently:
* Start "runConsistently" execution
* Peek the GC queue
* Lock the RowId
* Vacuum the row
* Repeat from step 2
The "vacuum" operation, in {{aipersist}} in particular, requires reading the
whole value from the storage, which is potentially expensive. What we can do
instead is
* "peek" N entries before executing the closure
* Make sure that engine "preloads" the data if that's necessary for the engine
* Only then start the closure, speculatively expecting that it won't lead to
as much IO while "holding the lock"
was:
What we do currently:
* Start "runConsistently" execution
* Peek the GC queue
* Lock the RowId
* Vacuum the row
The "vacuum" operation, in {{aipersist}} in particular, requires reading the
whole value from the storage, which is potentially expensive. What we can do
instead is
* "peek" N entries before executing the closure
* Make sure that engine "preloads" the data if that's necessary for the engine
* Only then start the closure, speculatively expecting that it won't lead to
as much IO while "holding the lock"
> Warmup gc entries before `runConsistently`
> ------------------------------------------
>
> Key: IGNITE-26998
> URL: https://issues.apache.org/jira/browse/IGNITE-26998
> Project: Ignite
> Issue Type: Improvement
> Components: storage engines ai3
> Reporter: Ivan Bessonov
> Priority: Major
> Labels: ignite-3
>
> What we do currently:
> * Start "runConsistently" execution
> * Peek the GC queue
> * Lock the RowId
> * Vacuum the row
> * Repeat from step 2
> The "vacuum" operation, in {{aipersist}} in particular, requires reading the
> whole value from the storage, which is potentially expensive. What we can do
> instead is
> * "peek" N entries before executing the closure
> * Make sure that engine "preloads" the data if that's necessary for the
> engine
> * Only then start the closure, speculatively expecting that it won't lead to
> as much IO while "holding the lock"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
