3 ms·
Just landed here to write this. Materialized Views are _very_ implementation specific and are definitely _not_ magic. It's important to understand how your imp
by 4ndrewl 1y ago
Just landed here to write this. Materialized Views are _very_ implementation specific and are definitely _not_ magic.
It's important to understand how your implementation works before committing to it.
- shivasaxena 1y agoCurious if anyone know any implementation where they would be automatically updated? Now that would be awesome! EDIT: come to think of it, it would require going through CDC stream, and figuring out if any of the tables affected are a dependency of given materialized view. Maybe with some ast parsing as well to handle tenants/partitions. Sounds like it can work?
- magicalhippo 1y agoMSSQL and Sybase SQLAnywhere has options for that, we use it a fair bit with both. At least on SQLAnywhere it seems to be implemented using triggers, ie not unlike what one would do if rolling your own.
- cyanydeez 1y agoPostgesql knows when you try to drop its dependencies so shouldnt be to hard to watch traffic
- 4ndrewl 1y agoOracle will do - a couple of options, either a full rebuild or an incremental rebuild.
- tanelpoder 1y agoAlso, latest Oracle version (23ai) has added "concurrent on-commit fast refresh" functionality, where concurrent transactions' changes are rolled up to the MV concurrently (previously these refreshes were serialized). https://oracle-base.com/articles/23/materialized-view-concurrent-refreshes-23 https://oracle-base.com/articles/23/materialized-view-concur... From the article: "Concurrent refreshes will only happen if there are no overlaps in the materialized view rows updated by each session."
- lsuresh 1y agoDo give us at Feldera a shot -- full IVM for arbitrary SQL + UDFs: https://github.com/feldera/feldera/ https://github.com/feldera/feldera/