-
Notifications
You must be signed in to change notification settings - Fork 17
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
Calling run() multiple times #30
Comments
Great observations.
This is what is done now. Ascent conservatively assumes that all relations may have changed, and recomputes all indices for the program. Here, it seems that this recomputing of indices is very expensive for some reason. This is something that can potentially be addressed. Although I'd have to think about its ramifications for BYODS.
This is also a possibility. But I prefer the other option. |
@s-arash thanks. |
I have yet to run into a case where calling run() multiple times does not cause a subsequent geometric increase in eval time, even when the row counts don't actually change. My programs are large but not super complex, and I don't think I'm doing anything too off the beaten path (using enum instances for values). My solution for now is to manage caches myself and break things down into multiple one-off ascent_run! calls. |
Right, I can't think of a good way to prevent removing facts from relations. Even replacing the
Ascent wasn't really designed for incremental processing of data. I can just disallow calling I have purposefully not hidden the internals of Ascent's relations and indices so they can be tinkered with by those who know what they are doing. |
@s-arash
(where ResultSet provides the contents of the relations after run, and the indices, but can't be used to run again) and /// Runs the program and allows it to be run later. Runs in general are not incremental, and may take longer time than rerunning from scratch, or may fail to account for facts manually removed from the input relation after the first run.
fn run_and_keep(&mut self) Alternatively, there could be some switch attribute on the macro itself, which would generate the fields by default as private, with appropriate getters (handing out shared references), but would allow advanced users to request an 'exposed internals' ascent program. |
I think mod/rerun will require add provenance (like add fact/remove fact) semantic.
changing edge (like remove edge(1,2)) will cause datalog rule not holds logically (some path(1,2), can't be inferred). |
If I understand correctly, ascent is't a 'differential datalog'-style implementation, but is optimized for batch processing.
The API does however allow .run() to be called multiple times, so users will eventually do it.
I did a little experiment:
The output is:
It seems to me that:
While (as I expected), removing facts from relations isn't supported.
produces
[(1,), (2,)]
[(1,), (2,)]
My question is, would it be possible to either:
The text was updated successfully, but these errors were encountered: