Bruno,First, I'd try upgrading to 3.2-5: you may be tickling a bug in 3.2-2. The upgrade process is quite simple and quick.
The combination of the range-index and the predicate [1] on your query should prevent the server from needing to load more than 1 fragment (it might actually read ahead by a few fragments, but that shouldn't matter).
140-kB is on the high side for a fragment, but isn't so large that I'd worry about it. Are you using any fragment roots or fragment parents in your database configuration? If so, what are they and how did you choose them?
If 3.2-5 doesn't fix the issue, and you have a support contract, this would also be a good time to contact support. I'd recommend including a support log, since that's the first thing they'll ask you for.
-- Mike Bieth, Bruno wrote:
Hi Mike, Thanks for your answer ! I'm using MarkLogic 3.2-2 and my expanded tree cache size is set to 128 MB. Some articles are bigger than 100 kB but the average is around 40 kB (BTW do you know how to get this information from MarkLogic ?). When I change "return $res" to "return xdmp..." it works and show the article URI. But I'm not sure to have enough knowledge to solve the problem. I still wonder : Does MarkLogic loads ALL the return values in the expanded-tree-cache even if I only request the first result (FLWOR[1]) ? I don't really understand what is going in this cache (the query and performance tuning guide is quite short on this). My forest has 2,563 active fragment and 1,563 deleted fragments which represent 576 MB on disk and 8 MB in memory. This represents effectively 1200 articles. Do you think the fragments are too big ? There is actually +10 times more articles so increasing the expanded-tree-cache might not be a solution ? Thanks, Bruno On 22/2/08 13:24, "Michael Blakeley" <[EMAIL PROTECTED]> wrote:Bruno, Your query looks fine to me, and the query-trace indicates that the server is using your range-index for the sort. What version of MarkLogic Server are you using, and how large is your expanded-tree-cache? I'm able to perform a very similar query on my laptop, using NLM Medline content. I created a string-index on ArticleTitle and ran this query against 30,000 citations: xdmp:query-trace(true()), ( for $i in //MedlineCitation order by $i/Article/ArticleTitle return $i )[1] The query returned one MedlineCitation, as expected. I'm using 3.2-5 and my expanded-tree-cache-size is 192; but I can lower it to 1-MB and the query still runs. These citations average only about 2 kB. If your expanded tree cache is small enough, and the top article is quite large, then the top article might be too large to fit in cache. The fact that you are able to run your query with a different sort might support this hypothesis. Try changing "return $res" to "return xdmp:describe($res)" in your query. That change should allow you to run the query, and the result may point to the problem. -- Mike Bieth, Bruno wrote:Hi, I¹ve some difficulties in ordering a search using a string element range index. This is my element range index config : * Scalar type : string * Namespace URI : (empty) * Localname : atl * Collation : http://marklogic.com/collation/ Here is my query : xdmp:query-trace(true()), (for $res in //article order by $res/fm/atl return $res)[1] Here is the log : 2008-02-22 07:46:03.448 Info: Docs: line 3: xdmp:eval(" xdmp:query-trace(true()), ((for $res in //art...", (), <options xmlns="xdmp:eval"><database>1615150627559396969</database><modules>0</module s><roo...</options>) 2008-02-22 07:46:03.448 Info: Docs: line 3: Analyzing path for $res: collection()/descendant::article 2008-02-22 07:46:03.448 Info: Docs: line 3: Step 1 is searchable: collection() 2008-02-22 07:46:03.448 Info: Docs: line 3: Step 2 is searchable: descendant::article 2008-02-22 07:46:03.448 Info: Docs: line 3: Path is fully searchable. 2008-02-22 07:46:03.448 Info: Docs: line 3: Gathering constraints. 2008-02-22 07:46:03.448 Info: Docs: line 3: Step 2 test contributed 1 constraint: article 2008-02-22 07:46:03.448 Info: Docs: line 3: Order by clause contributed 1 range ordering constraint for $res: order by $res/child::fm/child::atl ascending 2008-02-22 07:46:03.448 Info: Docs: line 3: Executing search. 2008-02-22 07:46:03.450 Info: Docs: line 3: Selected 1232 fragments to filter. But I get this : ERROR: eval-in Test at file:./Docs XDMP-EXPNTREECACHEFULL: for $res as item()* in collection()/descendant::article -- Expanded tree cache full on host devexist.nature.com Stack trace: line 3: 1: 2: xdmp:query-trace(true()), 3: ((for $res in //article order by $res/fm/atl return $res)[1]) 4: 5: xdmp:eval(" xdmp:query-trace(true()), ((for $res in //art...", (), <options xmlns="xdmp:eval"><database>1615150627559396969</database><modules>0</module s><roo...</options>) in /cq/eval.xqy line 111: I¹ve also defined an int range index on another field and when I order on this field it works fine (the log tells me as well that the range index is being used). There must something wrong in my server config but I really don¹t know where to look at. I¹ve followed the performance guide and everything look fine. Any idea ?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
