Re: busy message queues

On Mon, January 29, 2007 10:17 am, Roman Neuhauser wrote: > # bob@copienttech.com / 2007-01-29 11:09:13 -0500: >> We've been using Postgres for our messaging queues up to now, but >> our >> message volume seems a bit higher than what we'd expect Postgres to >> keep >> up with... many inserts/deletes from in/out queues seems to dirty a >> lot >> of memory and effect general database performance (we use the >> database >> significantly for other operations). > > ... > >> So, I'm leaning toward local sockets. I'm implementing this right >> now, >> so I can test the performance against the Postgres implementation. >> I >> will also implement and test other solutions if anyone can persuade >> me... ie. if you feel the msg_get_queue() stuff is worth the >> compile/installation effort. > > You'll be comparing a mammoth to a moth swarm. > > Do you actually need the persistence PostgreSQL gives you, or don't > you > mind if the other side is down? If you need to be sure that the > receiver > will process your message even if it's not up when you send the > message, > you'll end up reinventing a database. Seems to me that they'll re-invent the TCP "ACK" rather than a full-fledged RDBMS... :-) > What version of PostgreSQL are you using? > What's your vacuuming strategy? Another idea worth exploring would be something more lightweight like LDAP or MCache (MCacheD? MemCache? -- you'll know which one I mean when you find it) to share data or even try MySQL just to see if you can tune it easier/faster/better. I'm sure an expert PostgreSQL user can "win" this game, but you have to use the personell you have. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?