opteryx
opteryx copied to clipboard
🦖 A SQL-on-everything Query Engine you can execute over multiple databases and file formats. Query your data, where it lives.
Promote common parts of disjunctions to reduce the evaluation effort WHERE ( A = B AND C = D ) OR ( A = B AND E = F )...
If an evaluation isn't used, it may be able to be avoided, something like: ~~~sql SELECT column FROM ( SELECT MD5(column) AS hash, column FROM table ) ~~~ The MD5...
~~~sql SELECT 12.0 + DECIMAL(12.0) = 24.0 ~~~
this works: ~~~sql SELECT * FROM $planets WHERE '{\"a\":1,\"b\":\"c\"}'->'a' = id ~~~ this does not ~~~sql SELECT * FROM $planets WHERE id = '{\"a\":1,\"b\":\"c\"}'->'a' ~~~
Using a BRIN (Block Range INdex) in combination with partial sorting during compaction can be an effective strategy for improving the performance of queries over a large number of SST...
if we have a limit, we should push to the SQL reader but not past greedy ops like group and order, or reduction ops like a filter or join.
as an optimization strategy, moving all of the constants to the right of the equals should allow some folding of constants. This may provide two benefits; if we reduce to...
If `first_seen + 7 days > now` should move the now and interval to one side and calculate once rather than calculate for every row. This will save roughly 1...
two variables should affect the execution: - max_cache_evictions_per_query - disable_optimizer