Subsume should succeed even when the tuple is not present #487
Conversation
yihozhang
requested review from
FTRobbin and
saulshanabrook
and removed request for
a team
CodSpeed Performance ReportMerging #487 will not alter performanceComparing Summary
Benchmarks breakdown
|
| @@ -430,7 +430,7 @@ fn test_serialize_subsume_status() { | |||
| None, | |||
| egglog::SerializedNode::Function { | |||
| name: ("a").into(), | |||
| offset: 0, | |||
| offset: 1, | |||
There was a problem hiding this comment.
Why are there two a functions values now? They are equivalent right?
There was a problem hiding this comment.
The new implementation conceptually makes a new entry to the database with the new timestamp and marks the old entry as stale.
The old implementation directly modifies the old entry, which is bad because the database is supposed to be append-only I think.
There was a problem hiding this comment.
I think I tried to do it like delete? If that makes sense? Which does modify a row? Not saying it's right just curious what you think.
There was a problem hiding this comment.
I think remove is doing the following:
- Delete the entry from the offset table
- Set the actual tuple in the (append-only) log as stale (
self.vals[*off].0.stale_at = ts)
insert_and_merge (which is the safe way of updating the table) does the following:
- Mark the old tuple in the log as stale
- Append the new tuple to the log
- Update the offset table entry to point to the new tuple
While the old subsume implementation:
- Find the old tuple according to the offset table
- Update its subsumed flag
So I think it is unsafe (while remove and insert_and_merge are safe)
There was a problem hiding this comment.
Thank you for fixing this and looking into it so closely!!
|
Woops sorry @yihozhang I realized my review comments had been pending for two weeks sitting here unpublished! Didn't mean to leave you hanging |
saulshanabrook
force-pushed
the
yihozhang-fix-subsume2
branch
from
4820561 to
9684208
Compare
Subsumes #478 and fixes #462