On Mon, January 29, 2007 10:17 am, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 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
# [EMAIL PROTECTED] / 2007-01-29 12:49:37 -0500:
> > > > What version of PostgreSQL are you using?
> > >
> > > 7.4.x
> >
> > Too old, 8.1 and 8.2 have way better performance.
[...]
> Any predictions on what we might see for performance without upgrading
> the PG version?
No idea, but I wouldn
> > No. We don't need the persistence. I'm planning on
> managing the flow
> > and not sending the data if the app isn't available to
> receive it on the
> > other end.
>
> Will you need to resend?
Nope. Not in-line. We have an off-line message processing procedure to
handle the missed tr
# [EMAIL PROTECTED] / 2007-01-29 11:33:35 -0500:
> > 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 r
> > 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
> > c
# [EMAIL PROTECTED] / 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 genera
6 matches
Mail list logo
