At a glance it looks like it creates triggers on the fly and tears them down. I'm curious how scaleable this is, is trigger creation a locking activity in postgres?
Logical decoding was only recently added in Postgres (9.4)? I'm not sure on the privileges required for logical decoding in postgres, but typically it requires 'root' access because it lets you see all the data in the system. So triggers can often be used on a shared database, where you might not be allowed to access the transaction log.
It would be awesome to write a Postgres extension in C to implement Live Selects directly. Due to this project's developmental legacy this was considered from the start but is definitely on my radar.
This is a cool hack, but no latency compensation or database only on the server. I would rather use a package that adhered to the core principles of Meteor.
Whether this is the right approach or not, I'm glad to see people trying to make the meteor sql support happen. Many people aren't really to adopt Meteor unless it has sql support.
I think it's great to see this. I was really impressed by the insight/design of allowing the user to specify the invalidation functions, rather than trying to solve the (very difficult) problem of automatically determining the exact set of invalidation criteria. It may be that the user can determine a better invalidation function anyway, because they have domain-specific knowledge (e.g. how often a table changes).
(I'm a meteorite, but commenting in my personal capacity)
17 comments
[ 3.0 ms ] story [ 51.6 ms ] thread[1] Author - https://numtel.github.io/
At a glance it looks like it creates triggers on the fly and tears them down. I'm curious how scaleable this is, is trigger creation a locking activity in postgres?
Events can be triggered directly in PG using an extension for AMQP or something, or in a standalone service, using whatever you can dream up.
That said, thanks for pointing this out - it looks like yet another very useful PG feature!
edit: thanks for the link to logical decoding, looks very useful.
I would love to see a pull request for the "proper way." Thank you for your help.
It was way ahead it's time, maybe it's dead by now. But they still have the site here, weirdly named TelegraphCQ: http://telegraph.cs.berkeley.edu/
Direct link to 2.1 last version: http://telegraph.cs.berkeley.edu/telegraphcq/v2.1/
It would be awesome to write a Postgres extension in C to implement Live Selects directly. Due to this project's developmental legacy this was considered from the start but is definitely on my radar.
(I'm a meteorite, but commenting in my personal capacity)