From: | Joerg Hessdoerfer <Joerg(dot)Hessdoerfer(at)sea-gmbh(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Csaba Nagy <nagy(at)ecircle-ag(dot)com>, moises <moises(at)cedaivc(dot)co(dot)cu> |
Subject: | Re: Transaction Speed and real time database |
Date: | 2006-07-24 10:04:10 |
Message-ID: | 200607241204.10673.Joerg.Hessdoerfer@sea-gmbh.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 "relational" and "transactional" are orthogonal, they don't
> imply/require each other... most of the "roadblocks" you mentioned
> (including vacuum) is part of postgres transactional design and a
> non-transactional DB won't have that overhead. Your input enforces my
> thinking that the transactionality of the DB is the real roadblock...
> which means postgres will never really be an RT application in the
> proper sense of the word.
>
[...]
Yes, the terms are orthogonal. But most relational databases I know of are
also transactional - because it just makes sense.
The roadblocks I metioned were specific to PG. The storage manager is as it
is, no way around it. So you need vacuum, you can have index growth, and you
will have table space growth ;-)
Greetings,
Jörg
--
Leiter Softwareentwicklung - S.E.A GmbH
Mail: joerg(dot)hessdoerfer(at)sea-gmbh(dot)com
WWW: http://www.sea-gmbh.com
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2006-07-24 11:30:36 | Re: Allow commenting of variables in postgresql.conf to - try 4 |
Previous Message | Sergey E. Koposov | 2006-07-24 09:59:47 | patch implementing the multi-argument aggregates (SOC project) |