Hi,
On Monday 24 July 2006 11:26, Csaba Nagy wrote:
> [snip]
>
> > OTOH, one has to be very careful to not mix terms here. In industrial
> > (production floor) applications, the term 'real time database' refers to
> > soemthing completely different than a relational, transactional DB.
>
> But "rel
[snip]
> OTOH, one has to be very careful to not mix terms here. In industrial
> (production floor) applications, the term 'real time database' refers to
> soemthing completely different than a relational, transactional DB.
But "relational" and "transactional" are orthogonal, they don't
imply/re
Hi,
On Monday 24 July 2006 10:33, Csaba Nagy wrote:
> [please use "reply to all", otherwise you'll have what you just had: the
> guy who you write goes home for the weekend and all the rest of the
> people on the list who would answer you won't know there is soemthing to
> answer...]
>
> On Fri, 2
[please use "reply to all", otherwise you'll have what you just had: the
guy who you write goes home for the weekend and all the rest of the
people on the list who would answer you won't know there is soemthing to
answer...]
On Fri, 2006-07-21 at 13:39, moises wrote:
> Sorry if I can't explain me
Hannu Krosing wrote:
Ühel kenal päeval, R, 2006-07-21 kell 13:29, kirjutas Andrew Dunstan:
What you are asking is essentially the equivalent of asking "How long is
a piece of string?" The question is meaningless and so will be any
answer. The fact that there are web sites which are happy to
Ühel kenal päeval, R, 2006-07-21 kell 13:29, kirjutas Andrew Dunstan:
> What you are asking is essentially the equivalent of asking "How long is
> a piece of string?" The question is meaningless and so will be any
> answer. The fact that there are web sites which are happy to supply you
> with m
inal-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] En nombre de Martijn van
Oosterhout
Enviado el: viernes, 21 de julio de 2006 16:19
Para: moises
CC: 'Adnan DURSUN'; pgsql-hackers@postgresql.org
Asunto: Re: [HACKERS] Transaction Speed and real time database
On Fri, Jul 21, 2006 at
> [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 be
#x27;Adnan DURSUN'; pgsql-hackers@postgresql.org
Asunto: Re: [HACKERS] Transaction Speed and real time database
On Fri, Jul 21, 2006 at 09:38:41AM +0200, moises wrote:
> I want to know, in a hypothetical server, how many transaction postgres
> support for a first approximation.
>
> I f
On Fri, Jul 21, 2006 at 09:38:41AM +0200, moises wrote:
> I want to know, in a hypothetical server, how many transaction postgres
> support for a first approximation.
>
> I found this data of MySQL and DB4o data bases but I can´t find any of
> Postgres.
I think you're asking the wrong question. I
> Real time databases needs some other kinds of semantics and
> features that postgres don't have.
>
> Postgres don't supports real time constrains semantics in
> transactions. In other hands the concurrent transactions
> don't wok well based on priorities of task.
>
> The program scheduler o
Thanks for your answer,
I have experience with
postgres and I know perfectly that not a TOY.
But some concepts of real
time system don’t based only in speed.
Real time databases needs
some other kinds of semantics and features that postgres don’t have.
Postgres don’t supports re
12 matches
Mail list logo
