Re: Transaction Speed and real time database

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

In response to

Browse pgsql-hackers by date

  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)