Chris Withers wrote at 2006-6-27 09:56 +0100:
>Dieter Maurer wrote:
>> "PostGres" does use looks, lots of them and for different purposes.
>Could ZODB use locks to gain a similar performance boost?
Maybe, but it would be a really big change...
However, as I explained in an earlier message, the major
speed difference does *not* come from optimistic versus
pessimistic concurrency control (the optimistic approach
is usually more efficient) but from:
1. more efficient storage for highly structured data
2. relational databases support a limited set of
datatypes (tables, indexes) and know the behaviour.
Operations therefore can be executed by the server.
Object oriented databases, on the other hand, usually
support an unlimited number of datatypes where
the behaviour lives in the applications and
the server is stupid.
This causes high volumes of data to be exchanged
between the server and the clients
3. (unlike Andreas' feeling) the typical ZODB operation
modify much more objects than apparently similar
If for example 10 Zope objects are modified and
this cause the full text indexes to be updated
then this can cause more modifications than
the update of hundreds of Postgres rows
(as such rows cannot contain mass data -- due to the restriction
to simple types).
>> Most of our "ConflictError"s come from the session machinery -- because
>> conflict resolution works there only in a very limited way
>> (due to limited history availability).
>Would having more history help?
>> Yes, these are our hits -- despite the fact that our "increaser"
>> is much more intelligent (and increases only rarely and not
>Hmmm, mind if I commit that increaser to the trunk?
It's part of a proprietary extension product.
But, I can ask whether I can move over the essence to the
>There's a ZF board meeting some time soon after which you should get
>your official invite to become a committer member...
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org