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 materialize hint to the QueryOperator #36

Open
roveo opened this issue Apr 27, 2022 · 0 comments
Open

Add materialize hint to the QueryOperator #36

roveo opened this issue Apr 27, 2022 · 0 comments
Labels

Comments

@roveo
Copy link
Contributor

roveo commented Apr 27, 2022

There are database-specific performance issues with totals and such. Some databases are better at e.g. window functions, some at joins with group by subquery. To avoid having this logic in the backend (will make creating new backends more difficult), there are multiple solutions:

  • Have the engine attached to the backend. def __init__(self, backend: Backend) for the Engine. Then the backend can give hints to the engine about its preferences. For example, window_functions = True class attribute would mean that the engine prefers window functions, False that it's better to use groupby + join
  • The engine provides a hint materialize=True to the QueryOperator, so the operator will emit a DataFrame instead of a query and the rest of the computation will be performed using Pandas. This will surely improve database performance, but might affect local performance, especially important in case of the cloud version (out-of-memory errors). Using dask might alleviate this.
@roveo roveo added the engine label Apr 27, 2022
@roveo roveo added this to the Dictum 0.1.0 milestone Apr 27, 2022
@roveo roveo removed this from the Dictum 0.1.0 milestone Jul 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant