Hi Mike We will upgrade the server soon to the latest version.
I haven't set up any fragment root or fragment parents. So I guess there is a fragment per file (1 article per file). We do have support so I'll see with them when the server will be upgraded. Thanks ! Bruno On 22/2/08 15:42, "Michael Blakeley" <[EMAIL PROTECTED]> wrote: > 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</modul>>>> e >>>> 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</modul>>>> e >>>> 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 ? > > > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ********************************************************************************
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
