Roché Compaan wrote:
On Sun, 2006-07-02 at 17:46 +0100, Chris Withers wrote:
Yes, indexing seems to be the big problem here...
I wonder if there's a way to move indexing out of "the zodb".
The main things I get from ZODB are simplicity of data storage (ie: just
playing with python objects) and
On Sun, 2006-07-02 at 17:46 +0100, Chris Withers wrote:
> Yes, indexing seems to be the big problem here...
> I wonder if there's a way to move indexing out of "the zodb".
> The main things I get from ZODB are simplicity of data storage (ie: just
> playing with python objects) and robustness of da
Chris Withers wrote at 2006-7-2 17:46 +0100:
> ...
>Yes, indexing seems to be the big problem here...
>I wonder if there's a way to move indexing out of "the zodb".
>The main things I get from ZODB are simplicity of data storage (ie: just
>playing with python objects) and robustness of data.
>
>Fo
On 7/3/06, Jens Vagelpohl <[EMAIL PROTECTED]> wrote:
If you have a catalog-heavy site with high activity it does make
sense and is not hard to do. To really get a I/O benefit you should
have that ZODB served off a different disk drive or host, and if
you're on the same host served through a separ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3 Jul 2006, at 01:10, Lennart Regebro wrote:
On 7/2/06, Chris Withers <[EMAIL PROTECTED]> wrote:
I wonder if there's something to be said for having a generic object
indexing service that didn't use ZODB but used its own local
indexes and
re
On 7/2/06, Chris Withers <[EMAIL PROTECTED]> wrote:
I wonder if there's something to be said for having a generic object
indexing service that didn't use ZODB but used its own local indexes and
re-indexed as needed or if the indexes are corrupt?
Last week I got the interesting idea of using a s
Dieter Maurer wrote:
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
Dieter Maurer wrote:
...
> 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 re
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
Dieter Maurer wrote:
"PostGres" does use looks, lots of them and for different purposes.
Could ZODB use locks to gain a similar performance boost?
The only thing for which "Postgres" does not use locks is reading.
For this is uses MVCC (which we meanwhile adapted for the ZODB
to get rid of "R
Florent Guillaume wrote:
Chris Withers wrote:
Florent Guillaume wrote:
I can comment, I have a big brain too: the code in the catalog uses
per-connection series of keys, so no conflicts arise.
Really? I thought they were per-thread... wasn't aware that each
thread was tied to one connection
Chris Withers wrote at 2006-6-26 14:00 +0100:
> ...
>Ah, conflict errors, the bane of any ZODB app. Makes me wonder why other
>optimistic concurrency databases (I believe PostGres is one of these?)
>don't seem to exhibit the same problems...
"PostGres" does use looks, lots of them and for differ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Florent Guillaume wrote:
>>
>> BTrees perform best when keys' prefixes are randomly distributed.
>> So if your application generates keys like 'foo001', 'foo002',...
>> you'll get lots of conflicts. Same for consecutive integers
Chris Withers wrote:
Florent Guillaume wrote:
I can comment, I have a big brain too: the code in the catalog uses
per-connection series of keys, so no conflicts arise.
Really? I thought they were per-thread... wasn't aware that each thread
was tied to one connection indefinitely... I thought
Florent Guillaume wrote:
I can comment, I have a big brain too: the code in the catalog uses
per-connection series of keys, so no conflicts arise.
Really? I thought they were per-thread... wasn't aware that each thread
was tied to one connection indefinitely... I thought the connections
were
Andreas Jung wrote:
BTrees perform best when keys' prefixes are randomly distributed.
So if your application generates keys like 'foo001', 'foo002',... you'll
get lots of conflicts. Same for consecutive integers in IOBTree.
Tempted to call bullshit on this, since there's code in the catalog t
On 26 Jun 2006, at 15:02, Chris Withers wrote:
Florent Guillaume wrote:
BTrees perform best when keys' prefixes are randomly distributed.
So if your application generates keys like 'foo001', 'foo002',...
you'll get lots of conflicts. Same for consecutive integers in
IOBTree.
Tempted to cal
--On 26. Juni 2006 14:02:20 +0100 Chris Withers <[EMAIL PROTECTED]>
wrote:
Florent Guillaume wrote:
BTrees perform best when keys' prefixes are randomly distributed.
So if your application generates keys like 'foo001', 'foo002',... you'll
get lots of conflicts. Same for consecutive integer
Florent Guillaume wrote:
BTrees perform best when keys' prefixes are randomly distributed.
So if your application generates keys like 'foo001', 'foo002',... you'll
get lots of conflicts. Same for consecutive integers in IOBTree.
Tempted to call bullshit on this, since there's code in the cata
Jean Jordaan wrote:
The ZODB is actually very fast. [...]
So you're probably observing slowness in the frameworks on top of it.
I'll believe this anytime :-]
;-)
In our case, a transaction may be a workflow state change on say 50 objects.
Two or three people try a transaction like that wit
Roché Compaan wrote at 2006-6-23 19:04 +0200:
> ...
>In a test where one commits an instance of a Persistent
>subclass that have only 2 string attributes, 300 objects per second are
>created on average. Writing the exact same strings to a two column table
>in an RDBMS, yields more than 3000 records
Jean Jordaan wrote at 2006-6-23 16:24 +0200:
> ... write conflicts by large transactions ...
>To mitigate this, we want to create a savepoint and then commit more often
>while iterating and changing workflow, rolling back to the savepoint if
>necessary.
I fear this will not work -- at least not wh
On 23 Jun 2006, at 17:55, Andreas Jung wrote:
--On 23. Juni 2006 17:51:35 +0200 Florent Guillaume <[EMAIL PROTECTED]>
wrote:
BTrees perform best when keys' prefixes are randomly distributed.
So if your application generates keys like 'foo001', 'foo002',...
you'll
get lots of conflicts. Same
On Fri, 2006-06-23 at 15:11 +0200, Florent Guillaume wrote:
> > I often daydream of a ZODB that will one day have such great performance
> > that it won't be necessary to adopt a hybrid backend. I know there is a
> > huge difference between objects and records in an RDBMS, but in an
> > attempt to
--On 23. Juni 2006 17:51:35 +0200 Florent Guillaume <[EMAIL PROTECTED]> wrote:
BTrees perform best when keys' prefixes are randomly distributed.
So if your application generates keys like 'foo001', 'foo002',... you'll
get lots of conflicts. Same for consecutive integers in IOBTree.
hm..
Jean Jordaan wrote:
The ZODB is actually very fast. [...]
So you're probably observing slowness in the frameworks on top of it.
I'll believe this anytime :-]
In our case, a transaction may be a workflow state change on say 50 objects.
Two or three people try a transaction like that within a c
> The ZODB is actually very fast. [...]
>
> So you're probably observing slowness in the frameworks on top of it.
I'll believe this anytime :-]
In our case, a transaction may be a workflow state change on say 50 objects.
Two or three people try a transaction like that within a couple of seconds
Roché Compaan wrote:
I love the ZODB, and I am sure that I don't have to explain why, to
anybody on this list. I love it so much that it often clouds my
judgement. Sometimes I really should be using a relational backend but I
don't - the ZODB is just too convenient, and I don't have to complicate
28 matches
Mail list logo
