Hi there,
Is the above supported? What I mean is, I have a field that is defined maxOccurs=unbounded, created index “standard and text”. When I run ino:explain ( my query ), it told me that ino:postprocessing=“TRUE”. How can I solve this? Frankly speaking, is this case logically correct (want to sort by a unbounded field)?
Best regards,
Lun
Hello Lun,
could you please post the schema and the query, and let us know which version of Tamino you are using?
Thanks in advance,
Trevor.
Hi Trevor,
We are using Tamino XML Server 3.1.2.1, and please find our attached schema.
Best regards,
Lun
hklit.tsd (8.71 KB)
Hello Lun,
I loaded the schema that you provided (into a Tamino 3.1.2.1), made a simple instance with 3 occurrences of the “creator” element and loaded the instance 5 times.
Even a simple query like /article sortby(.) returns postprocessing=“TRUE”, so I would guess that the sortby is always handled by the postprocessor with my test data.
I have heard that some cases of sortby are actually handled faster by sorting the results in postprocessing, rather than trying to do it via indices.
I believe that the threshold for this behaviour is adjustable in Tamino 4.1.
Greetings,
Trevor.
[This message was edited by Trevor Ford on 01 Mar 2003 at 01:51.]
Hi Trevor,
But our database contains around 100,000 documents, and is increasing, it’s nearly an infinite process (in fact, I’ve never seen it sorted, everytime I aborted) if I issue the query and sortby creator. It’s ok for other field that only allow one occurence, over 100,000 documents can be sorted around 3 seconds! Sort by creator is indeed our project requirement. So, any workaround?
Many thanks and best regards,
Lun
Hello Lun,
could you estimate how many occurrences of the creator element there are? For example, if there are 10 per document, you would have 1 million occurrences in Tamino.
Could you also please post the actual query that is causing problems?
(Is the problem the duration of the sortby query is too long?)
Thanks,
Trevor.
Hello Trevor,
It’s strange that when I backed office this morning and ran the query again, it responsed almost as fast as sortby other field. The query that I mentioned to have problem is just as simple as “/article sortby (createor asc)”, I just wondering why the speed is back to good now. I havn’t restarted anything, non have changed any server properties…etc.
But, ino:explain(/article sortby (creator asc)) still gives me,
- xql:result
<ino:explanation ino:preselection=“FALSE” ino:postprocessing=“TRUE” />
</xql:result>
Is it really still OK if postprocessing exists?
Best regards,
Lun
Hello Lun,
what was the exact timeline for the creation of the schema, loading content, and so on?
Is it possible that you defined an index after loading the documents, and that the index was still being created when you tried the first queries? (So now it is faster because the indexes have all been built…?)
Perhaps one of the Support guys has already had some experience with this kind of scenario with Tamino 3.1.2.1, and would like to comment?
Regards,
Trevor.