Hi, Because it could help (even if nobody seems to use this feature ;-)), here is how I finally solved my performance issue.
I was using a timestamp computed from the client side (javascript). And the first time I query with this timestamp it made up to 40 seconds to return the results. Now, if the timestamp is not set (non paginated query), I return the timestamp using the xdmp:request-timestamp() function along with the result. Subsequent query then use this timestamp and now, even with the first « pagination » call, the result is returned as fast as expected. Regards, Stéphane > Le 17 juin 2015 à 14:38, Stephane Toussaint <[email protected]> > a écrit : > > Hi, > > I recently try to use Point In Time Queries as a workaround for « Safe > pagination searching in updatable environnement », but encounter some > performance issues. Short explanation of what I’ve done so far : > > - I initiate a search without a particular timestamp which returns the first > n results. > - Now if I want to navigate in pages but because content may be created or > updated, and because it may change the result sequence, I switch to « Point > in Time search query ». To do this, I simply use the timestamp at which the > new search was initiated (and keep that timestamp for page navigation. It > will be reset if search changed). > > It works as expected except that, the first time a query is triggered using > the timestamp (see code behind), the query is « abnormally » long; 10 up to > 40 seconds instead of a few milliseconds. > > xdmp:invoke-function( > function() {search:search("", $options, $offset, $pageSize)}, > <options xmlns="xdmp:eval"> > <timestamp>{$timestamp}</timestamp> > </options> > ) > > The query itself is quiet simple in my reproductible case, it’s only a > cts:collection-query. > > Is there some known performance issue with point in time queries ? > Extra question, is this a feature you judge appropriate for this use case ? > > Thanks for help, > Stéphane > > PS : I use ML 8.0, I do understant that fragments are now kept for 1 hour > even if no timestamp merge is set, it's enough for my use case and works as > expected
_______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
