On Fri, 2005-06-03 at 08:43 -0400, Christopher Browne wrote:
> After takin a swig o' Arrakan spice grog, pgsql@xxxxxxxxxx (Marco Colombo) belched out:
> > The hardware seems to be the bottleneck. Try improving the performance
> > of your disk systems. It's very unlikely to get _exactly_ the same
> > figures from such two different RDBMS. You expect them to be close, but
> > not identical.
>
> If the bottleneck is in the identical place, and they are otherwise
> well-tuned, it is actually *not* that surprising that the timings for
> "PostgreSQL vs real InnoDB" would be pretty close.
>
> If both are being bottlenecked by the same notion of "how fast does
> the disk spin," then the differences in performance won't be dramatic.
That's my point. If the purpose of the test is to compare "PostgreSQL vs
real InnoDB", there should not be any other bottleneck than software
itself.
> > BTW, make sure the test correctly emulated multiple clients (say 25,
> > 50 or 100). There's little point in stressing transaction support of
> > a RDBMS when there's only one single actor in the system, and
> > therefore no contention. Transaction code takes always the fast path
> > that way and you're testing the less important part of it.
>
> Actually, if you can demonstrate near-identical performance under a
> common set of conditions, that's a really useful datum to start with.
>
> It would then certainly be interesting to see how the behaviour
> changes as various stresses are introduced...
I take the purpose of the test is also to measure performance under
transactional load. Otherwise, inserting 1,000,000 rows one transaction
a time is just silly. I was able to do 12,000 row/s with COPY on very
cheap hardware (that's 1,000,000 rows in about 90 seconds, not minutes).
I think that if you benchmark how things perform in doing silly things,
you should expect silly results...
So, if you want transactions, make them _real_ transactions. One client
sequentially issuing transactions means nothing in this context.
Transactions is all about contention. You need a bunch of concurrent
clients processes, at least, and possibly a N-way system on the server
(to measure "real" contention at OS level too).
Otherwise you'd better measure many inserts per transaction (and COPY in
PostgreSQL) on a single client (which does make sense on its own).
.TM. (who has not been to Arrakis recently)
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
