Skip to content
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

Query planner interface #25

Open
smburdick opened this issue Apr 1, 2018 · 2 comments
Open

Query planner interface #25

smburdick opened this issue Apr 1, 2018 · 2 comments

Comments

@smburdick
Copy link
Collaborator

smburdick commented Apr 1, 2018

Since we're writing 2 different query planners/optimizers, the interface should probably be the same for both. I think the argument could just be a list of ranges, with each range containing alternating elements: machine ID's, followed by the list of vectors we want from that machine. We could put each range in its own list.

query_plan(r1 = [
m1, [v1, v2, ... vn]
m2, [v1, v2, ..., vn]
...
],
r2, r3, ...)

It could return a list of machines to visit, in a particular order. You could get away with returning just the machine IDs as the master could deduce which vectors to visit, but for simplicity each machine ID could be accompanied by the vectors you should retrieve from it.

@smburdick
Copy link
Collaborator Author

For my iter-prim I ended up using this interface

[(v0, (m00, m01)), (v1, (m10, m11), ..., (vn, (mn0, mn1))]
...

Instead, I'm giving it the vectors and options for the slaves, which is information used in the algorithm. However, at this stage it'd be worth trying it both ways, and it wouldn't be a big deal to support both if you want, and maybe pick the best one.

@smburdick
Copy link
Collaborator Author

smburdick commented Apr 4, 2018

We could write a Python function that transforms one representation to the other since they are informationally equivalent to support both formats from the C code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant