Knut Anders Hatlen wrote:
I haven't been thinking about the details, but at least it seems like
this is what PostgreSQL and MySQL do. This blocking behaviour is an
issue only in read committed mode, right?
I found your comment very interesting because it made me realize
that I hadn't been thinking about how concurrency control and
isolation levels play into this analysis.
So, a question, and an observation:
1) When you did the original analysis, are you sure that all
4 configurations that you tested (Derby client, DB2 client, MySQL,
and Postgres) were using exactly the same isolation level and
transaction settings? If you accidentally had one of your tests
running with different settings, the measurements could have been off.
2) Isn't it true that Postgres uses a versioning-based implementation
of isolation, rather than a locking-based implementation? If so, that
may have major implications for a benchmark like this, because Postgres
is basically trading off increased complexity at the server side for
less round-trips to communicate things like lock requests and releases.
thanks,
bryan