-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
persist: count compaction fast-path eligible reqs #18380
persist: count compaction fast-path eligible reqs #18380
Conversation
} | ||
if let Some(single_nonempty_batch) = single_nonempty_batch { | ||
if single_nonempty_batch.runs.len() == 0 | ||
&& single_nonempty_batch.desc.since() != &Antichain::from_elem(T::minimum()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically we can only stop compacting it when the since is past the upper (otherwise we might get some consolidation from forwarding the timestamps), but this is probably close enough to give us a signal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we'd see that in practice, because the upper of the output will also get bumped each time through, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not necessarily. like the upper of the shard could be at 7 and we could end up compacting [0,2) and [2,4)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC the most common case of this was a mostly-empty shard that looks like [0, 1)
(with data), followed by empty [1, 2)
, [2, 3)
, ... progress batches that didn't get the empty-batch shortcut. so each time compaction fires, it gets an input of all the batches, and so in practice the upper would advance each time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, good point. I don't think it would be correct to use the logic you have here to trigger the optimization, but it's certainly safe to use as an upper bound on the potential benefit of the technique
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's fair -- I mostly want a ballpark on whether fast-path compactions are like, 1%, 10%, 50% of our writes. I'm related-ly curious about TimelyDataflow/differential-dataflow#277 which seems like it'd help address your point here without having to compact a batch that will never benefit from logical compaction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ha, I was about to point you at that PR! last time I took Frank's temperature on it, he was pretty hesitant to make any scary changes to the DD Spine, but I think it's a pretty straightforward cherry-pick to apply it to our fork
Seeing how much compaction work / S3 PUTs we could shave off if we reintroduce the compaction fast path for single non-empty batches (with 1 run and were written by compaction)
Motivation
Tips for reviewer
Checklist
$T ⇔ Proto$T
mapping (possibly in a backwards-incompatible way) and therefore is tagged with aT-proto
label.