wernerdv commented on code in PR #13554:
URL: https://github.com/apache/ignite/pull/13554#discussion_r4080597108
##########
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/RowStore.java:
##########
@@ -132,8 +133,25 @@ public void addRow(CacheDataRow row, IoStatisticsHolder
statHolder) throws Ignit
* @param statHolder Statistics holder to track IO operations.
* @throws IgniteCheckedException If failed.
*/
- public void addRows(Collection<? extends CacheDataRow> rows,
- IoStatisticsHolder statHolder) throws IgniteCheckedException {
+ public void addRows(Collection<? extends CacheDataRow> rows,
IoStatisticsHolder statHolder) throws IgniteCheckedException {
Review Comment:
The primary advantage is that only the minimum required for the largest
single row is evicted, not the entire batch upfront.
The reserve is non-exclusive (shared emptyDataPages counter), so even
sum-reserve does not guarantee pages for this batch — concurrent writers can
consume them, and the re-reserve in takePageWithReserve is still needed.
WriteRowsHandler packs multiple small rows into one page, so sum(rowSizes) /
pagePayload is a pessimistic upper bound: live entries are evicted for pages
that packing would never use.
Max-row reserve evicts only what the largest row requires; the remainder is
picked up per-page by the re-reserve in insertDataRows → takePageWithReserve —
exactly at the point of need.
Under contention both approaches degrade to the same per-page re-reserve.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
