Adar Dembo has posted comments on this change. ( )

Change subject: KUDU-2693. Buffer blocks while flushing rowsets

Patch Set 1:

(1 comment)
Commit Message:
PS1, Line 13: This means that, instead of each flush
            : requiring its own LBM container, many of the output blocks can be
            : consolidated into a small number of new containers (typically one 
            : disk).
> Yea, the skepticism there is that, even if we put the blocks for a column i
We talked about this on Slack; I'm posting a summary for posterity.

The flush itself preserves key ordering within the rowset. As such, ordering 
rowsets by "time of flush" could yield a sequential scan (provided it's 
UNORDERED). However, that flush time ordering is discarded when a new rowset 
enters the RowSetTree: when queried, the tree will yield intersecting rowsets 
in start key order. If we cared about sequential block access within a 
container, we'd have to reorder the rowsets by rowset ID before scanning. 
Sequential scanning vs. buffering of written data presents a read/write 
tradeoff, so even long term it may make sense to support both and allow users 
to choose on a by-table basis.

Could you include a brief summary of this discussion in your commit message?

To view, visit
To unsubscribe, visit

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Iacc662ba812ece8e68b0ef28f4ccdf0b7475fbc0
Gerrit-Change-Number: 12425
Gerrit-PatchSet: 1
Gerrit-Owner: Todd Lipcon <>
Gerrit-Reviewer: Adar Dembo <>
Gerrit-Reviewer: Andrew Wong <>
Gerrit-Reviewer: Andrew Wong <>
Gerrit-Reviewer: Grant Henke <>
Gerrit-Reviewer: Kudu Jenkins (120)
Gerrit-Reviewer: Mike Percy <>
Gerrit-Reviewer: Todd Lipcon <>
Gerrit-Comment-Date: Wed, 13 Feb 2019 07:47:41 +0000
Gerrit-HasComments: Yes

Reply via email to