From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
---|---|
To: | moises <moises(at)cedaivc(dot)co(dot)cu> |
Cc: | 'Martijn van Oosterhout' <kleptog(at)svana(dot)org>, 'Adnan DURSUN' <a_dursun(at)hotmail(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transaction Speed and real time database |
Date: | 2006-07-21 17:28:19 |
Message-ID: | 1153502899.5683.312.camel@coppola.muc.ecircle.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> [snip] Suppose that every
> body say me that POStgres is to slow for real time databases, then I will be
> very full trying to resolve this problems with postgres, don't think that?
I think you didn't understand correctly: postgres is not slow, it is
just not suitable for real RT applications because of a few reasons,
which in fact make other data bases also not suitable for this purpose.
The main concern is that a RT application usually needs predictable
response times, possibly with guaranties for upper bounds of response
times... and most data bases which are transactional and offer
concurrent access won't give you such guaranties, due to locking issues.
The question is, your application is really RT in the proper sense of
the word, or it is just an OLTP application which needs to be fast but
won't cause a nuclear explosion if one response in 100 will be slower
than expected... in that case postgres might be good for you.
Cheers,
Csaba.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-07-21 17:29:10 | Re: Transaction Speed and real time database |
Previous Message | Josh Berkus | 2006-07-21 17:02:21 | Re: Units in postgresql.conf |