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

Add a way to specify a preferred store which should be used for queries #439

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

gartens
Copy link
Contributor

@gartens gartens commented Apr 6, 2023

Summary

This is a prototype on how users can influence the data store chosen by Polypheny. At the moment it is only implemented for SQL queries and it operates on a table as a whole, this might very well be expanded to column level (hence why it is parsed as part of a compound identifier). The handling of the preference inside the router is still not optimal.

How to use

Let's assume we have a table orders that is placed on two stores with the unique names p and q. The store p is very fast and q is slow. For an interactive request the programmer can have Polypheny use the fast store with query like this:

    SELECT order_id, order_date, ... FROM orders @ p WHERE ...

But when running large scale analysis, where slower load times are acceptable, the query is routed to the slow store:

    SELECT order_id, order_date, ... FROM orders @ q WHERE ...

Testing

Place a table on two stores. Then query the table with the syntax above in the UI. In the routing tab on the left, it should show that the selected placement was used (or at least preferred when not all columns were present on the selected store).

Bugs

  • Any identifier can be annotated. No warnings or errors are given when this annotation has no effect.

  • No special error handling or warning when the placement does not exist.

  • Only implemented for the SimpleRouter so far. Should be fairly easy to extend
    to the other routers as well.

  • Other placements are used if the preferred one does not have all the columns. (this might be a feature)

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

Successfully merging this pull request may close these issues.

1 participant