11 ms·
Looks like it’s Postgres protocol compatible rather than running as a Postgres extension? I’ve been keeping an eye on work that’s been done to support this int
by aidos 6y ago
Looks like it’s Postgres protocol compatible rather than running as a Postgres extension?
I’ve been keeping an eye on work that’s been done to support this internally in Postgres. Looks like it’s still moving along. I guess it’s a pretty tricky puzzle (especially once you add aggregates). Depending on the performance implications, it would sit in a pretty sweet spot for some usecases. For example, at the moment I have a form of materialised view that’s simple too slow to build from scratch. My compromise is to run periodically, figure out which subset of the table needs refreshing and update just those rows.
https://wiki.postgresql.org/wiki/Incremental_View_Maintenance https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc...
- namibj 6y agoIt doesn't run as an extension (at least that's not the typical deployment, and I'd be surprised if it did). You can feed a CDC to Materialize and either feed the output back to Postgres, or just query it directly in Materialize (via a normal postgres client). It's very likely that you can cut the typical maintenance latency down below one second. Currently that likely involves using a Kafka broker between the two databases, but feel free to plop in the community Slack [0]. [0]: http://materialize.com/s/chat http://materialize.com/s/chat