Tor Rustad wrote, On 29/10/07 23:50:
> Dann Corbit wrote:
>> Flash Gordon" <spam@flash-gordon.me.uk> wrote in message
>
> [...]
>
>>> Increasing the number of reads and writes by 10% would be unpopular
>>> unless it brought some other massive benefit, and your proposed
>>> change would not provide my customers with any benefit, only costs.
>>
>> I suspect that MonetDB may be ful for your application.
>> Frequently, read based problems have a huge benefit from in-memory
>> column storage (e.g. 10-100x faster).
>> You would need at least one machine with large memory, though.
>
> I rather suspect, nobody would really want to replace their financial
> DB2 or Nonstop DB systems. Changing the DB infrastructure on a
> business-critical system, could be very expensive.

It would be, especially as we have not yet gone as far as using an SQL
engine. We are actually using DIsam.

We are actually looking at moving to SQL databases as the back end and
have a long-running project working on the port, but there are specific
commercial reasons for the SQL engines we need to support.

> Performance requirements might be important, but correctness, risk,
> fault-tolerance, disaster-recovery, scalability, fail-over-time etc. are
> typically more important, at least if Gordon is not talking about some
> back-office system, but rather an online transaction environment, like
> e.g. a stock-exchange or an EFTPOS host.

It is a major back-office system. It is the system that a number of
large companies are using for entering all their requisitions, orders,
invoices and goods received notes, matching invoices to GRNs and lots of
other stuff. Also lots of reporting on all this data. It is business
critical for the companies using it.

> There is no simple answers to tuning such high-integrity systems, and
> the usual lesson apply, first perform measurement to identify the
> bottlenecks. If no benefits, don't do it.

Actually, the first rule is do not even consider looking at it or
bothering doing any measurements unless there is known to be a good
reason to start looking. As long as the code is fast enough (which it is
currently) we will concentrate on writing code to meet new and changed
requirements as correctly as possible and fixing the existing bugs. We
will only worry about measuring when there is a performance problem
significant enough to be worth the costs of investigating it.
--
Flash Gordon