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
