Re: Transaction Speed and real time database

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.

In response to

Browse pgsql-hackers by date

  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