> From: Jim Nasby [mailto:Jim.Nasby@BlueTreble.com]
> My guess is this is a test scenario that completely favors VoltDB
> while hamstringing Postgres, such as using no transaction durability
> at all in VoltDB while using maximum durability in Postgres. Comparing
> the cost of every COMMIT doing an fsync vs not could certainly produce
> a 25x difference. There could be other cases where you'd get a 25x
> difference.
I guess my question then is: how much do you pay for that durability? If you benchmark Postgres configured for pure
in-memoryusage with absolutely no writes to disk (or SSD or network), where is it spending its time? Is there a lot of
overheadin getting data in and out of cache buffers and conversions and in concurrency control?
As a case study, assume an RBMS is required to monitor and record Internet (or phone or VHF) traffic. If the power goes
offthe traffic continues, and it really doesn’t matter whether you lose 60 seconds of down time or 63 seconds; in any
caseanother instance in another data centre will pick up the slack. So the requirement is atomicity yes, but not
durability.Should you bid Postgres for the job, or look elsewhere? How much slower would Postgres be than a competitor?
Dowe care?
> You need to be careful of benchmarks from commercial companies. MySQL
> used to tout how fast it was compared to Postgres, using a benchmark
> it created specifically for that purpose that had very little to do
> with the real world. People eventually discovered that as soon as you
> had a concurrent workload Postgres was actually faster.
Of course; but at the same time insisting on including durability favours Postgres when I'm actually asking about
alternatives.
Regards
David M Bennett FACS
Andl - A New Database Language - andl.org