31–40 of 87 posts
Sooo...Materialized/Indexed Views?
Correct me if I'm wrong, but Materialized Views have the limitation that you need to refresh the entire view! Often you know which rows will change based on the data you receive.
Databases like PostgreSQL don't offer insights into the query plans, does EventReduce parse the SQL statements to determine which tables and rows will be affected by a query and run the appropriate caching or cache invalidation logic?
Materialize exists to efficiently solve the view maintenance problem: https://materialize.io/
They also allow for arbitrary joins. Basically every valid SQL query can be turned into a stream by Materialize which is pretty amazing. This algorithm is limited to single table aggregates I think?
In addition, it also tracks the history of changes and hence allows the cursor to go back if needed with "resumeToken"
Databases like PostgreSQL don't offer insights into the query plans, does EventReduce parse the SQL statements to determine which tables and rows will be affected by a query and run the appropriate caching or cache invalidation logic?
Did I understand this correctly? You have a single set of items which you query by evaluating a predicate on each of them and then sort the matching ones. After the initial query you update the query result by looking at all the data update events, i.e. you remove delete items from the result, you insert matching new items in the correct position according to the sort order and you insert, remove, or move updated ite…
Yes this is correct. The performance benefit comes from doing all this stuff on the CPU instead of using disc-io. Also the internal binary decision diagram of EventReduced is optimized in a way to run less logic then a query would do. This makes it even faster then running the query again with an in-memory database.
Databases like PostgreSQL don't offer insights into the query plans, does EventReduce parse the SQL statements to determine which tables and rows will be affected by a query and run the appropriate caching or cache invalidation logic?
PostgreSQL does offer insights into the plan. Just put EXPLAIN before your query.
However, you can't ask ask PostgreSQL to run a query and also return the query plan used for said query.
Earlier quoted context omitted.
PostgreSQL does offer insights into the plan. Just put EXPLAIN before your query.
Right but that's when you explicitly ask for it. However, you can't ask ask PostgreSQL to run a query and also return the query plan used for said query.
Databases like PostgreSQL don't offer insights into the query plans, does EventReduce parse the SQL statements to determine which tables and rows will be affected by a query and run the appropriate caching or cache invalidation logic?
How so?
https://www.postgresql.org/docs/current/sql-explain.html
https://stackoverflow.com/questions/7359702/how-do-i-obtain-...
https://mariadb.com/kb/en/analyze-statement/
https://docs.oracle.com/cd/B19306_01/server.102/b14211/ex_pl...