Comment by quectophoton

Comment by quectophoton 15 hours ago

6 replies

> And then by magic the results of this query will just always exist and be up-to-date.

With PostgreSQL the materialized view won't be automatically updated though, you need to do `REFRESH MATERIALIZED VIEW` manually.

jelder 4 hours ago

Did I miss in the article where OP reveals the magic database that actually does this?

3rd party solutions like https://readyset.io/ and https://materialize.com/ exist specifically because databases don’t actually have what we all want materialized views to be.

4ndrewl 15 hours 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 15 hours ago

    Curious 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 7 hours ago

      MSSQL 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.

dalyons 14 hours ago

Postgres materialized views are pretty terrible / useless compared to other rdbms. I’ve never found a usecase for the very limited pg version.

  • thrown-0825 11 hours ago

    having a dataset refresh on a timer and cache the result for future queries is pretty useful