jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Performance as compared to simple sql db query is quite bad
Date Fri, 01 Feb 2008 12:21:14 GMT

> On Feb 1, 2008 1:49 PM, zevon <sateeshl@expedia.com> wrote:
> > I am afraid I might not be able to use '//*' everytime, the given 
> > example was the simple one, but for each of these type 
> nodes, I would 
> > have nodes which carry other information and one referring 
> the other. 
> > Doing a  scan everytime and filtering out unwanted would be 
> expensive too.
> For best search performance with the current Jackrabbit query 
> indexes, you'll want to use a node type or property 
> constraints instead of a path check.
> For example, if all your friendly file ids are stored in 
> properties named "my:friendlyFileName", the XPath query 
> //*[@my:friendlyFileName] should give you pretty fast access 
> to all the nodes with such properties.

Or on some nodetype like:

//element(*, mynt:paragraph)[@myapp:title="Node Types"]

path queries involve hierarchical checks which need to be resolved
dynamically. A more fair test would be to create in one database table a
enormeous hierarchical structure by rows having a parent id, and then do
some sql query to only have rows that have some certain parents, which
have certain parents, which have... etc etc

Your comparison is totally different.


> BR,
> Jukka Zitting

View raw message