4 ms·
How do you mean? Couldn't you use a trigger to update the view?
by petepete 10y ago
How do you mean? Couldn't you use a trigger to update the view?
- phamilton 10y agoEffectively yes, but if it's that simple why not make this a built in functionality? Other DBs have it.
- mozumder 10y agoTriggers on materialized views are really error-prone and tedious. It's cache invalidation, which is hard.
- ams6110 10y agoIMHO triggers are almost always best avoided. There are some exceptions but most of the time you want changes to be explicit not happening "by magic" behind the scenes as a side-effect of something else.
- okket 10y agoA trigger on what? Every update, insert, delete, etc.? On every table in the view? Even if that is possible, it may be a major performance killer. This has to be done internally, I think.
- jeltz 10y agoI am not sure it necessarily would be that bad. After all foreign keys are implemented with triggers and they are usually fast enough. You just need to write trigger functions which are fast enough.
- gnaritas 10y agoIt is possible, that's how I do it, and it doesn't really affect performance at all. You just don't do it real time, the triggers just kick an id into a queue and you have a background task work the queue updating the materialized table from the view it's a copy of just for the id's in the queue.
- petepete 10y agoSo what would make the MV self-update?