> So far I couldn't reproduce the problem. The size (280 MB) could have > another reason, maybe the database does not re-use empty space for > some reason. When I had a similar problem, I also had a really large > database (about 1 GB), but after compressing it was only 10 MB or so. > It was not MySQL. My suggestion is:
> - Before running the test, clean the database - After the test, display the number of rows in the database, and the size > Without reproducible test case, it is hard to find the problem. If the > size reproducibly grows much faster than the number of rows, I would > be interested in finding out why, or finding a workaround. The number of rows was increasing also very fast. When my default_node table reached 22 GB, it was holding 35 million rows. > Query q = manager.createQuery( > "//contractors/element(*, nt:base)[EMAIL PROTECTED]" + id + "]", > Query.XPATH); The problem here is that if you use predicate on the node with plenty of instances (say a contract), the search works fine, the problem is if the search has to look at all the instances of this type of node. > I was told that a few thousand child nodes is not a problem, but if > you expect 30000 or more, then you should consider using a deeper > hierarchy (with the current Jackrabbit) because there is a performance > degradation. We actually plan a 100K nodes repository, with an extreme limit to 250K, which could possibly mean something like a maximum of 25K to 30K child nodes, with an extrele limit to 60K to 80K child nodes. AND searching them ;-) Frederic Esnault
