node.js - Postgres dynamically creating listeners -


i have web site, backed postgres database. there multiple webservers, maintain persistent connections each client, , needs notify them of relevant events. changes 1 web-server may effect user connected web-server, need messaging layer between web-servers. ideally i'd use database this, keep things simple.

so 2 obvious ways, see, be:

1) have webserver listen all events, , web-server side filter ones useful (e.g. relates users has connection with).

or:

2) dynamically create listener each client connects, , remove listener when client disconnections.

the first way means lot of useless data going on wire, easy webserver filter (a simple hashmap lookup). second way looks ideal if postgres implemented in such way can have thousands (to tens-of-thousands) of listeners created @ time.

btw i'm using latest version of postgres

thoughts?

thanks much!

ok, notify client, have use sort of persistent, stateful connection, websocket. there number of ways address load , performance there won't discuss don't have narrow enough area discuss implications , solutions.

for database-side, "thousands" still relatively small in number in database terms, , listeners don't affect planner don't see reason why problem. however, there 3 things consider before go direction.

  1. number of database connections. don't want thousands of database connections. way madness lies. if going thousands of listeners should relatively small number of connections.

  2. this atypical use of listeners, leading atypical quantity. because don't see reason why wouldn't work doesn't mean might not run problems. did light-weight testing , didn't find significant performance implications of ten thousand listeners. expect small amount of memory used each listener , sequential scan of listeners table perform (and woudl cached in memory anyway if used).

  3. listen/notify provides little security. want couple sort of tables storing payload rather pass along in payload of notify statement. thousands of tables more cause problems thousands of listeners, because planner has think number of tables in planning sql statement.

if this, set catalog of clients each connection claimed, , set 1 listener connection. set single table payload data, , since each connection claim part of table, ignore concurrency problems on db side. again solution. there may others. don't see obvious problems large numbers of listeners, aware heading territory, if go way, few have gone before. suspicion number of listeners least of worries, however.


Comments

Popular posts from this blog

c++ - CryptStringToBinary API behavior -

java.util.scanner - How to read and add only numbers to array from a text file -

iphone - Three second countdown in cocos2d -