[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. > Because of the features of a full-fledged relational database engine, > engineers often wish they had one of those instead ;-). Usually, we solve > this with some sort of streaming 'frontend', which buffers the data flow > (usually to disk) until it's inserted into the database. This lowers the > real-time requirement to 'has to be fast enough on average'. We have several > of these types of applications in production at various customers, some for > 6+ years continuously (using PostgreSQL 7.0!). This sounds the most reasonable approach :-) Cheers, Csaba. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
