Christian: Oops, you're right. Some of the qstn elements have a qstnLit child. The ddi:qstn/text() solved the problem, likewise if I use ddi:qstn/ddi;qstnLit
Now an interesting one is that if I use a different database that contains ddi:var/ddi:labl elements but does not contain any ddi:qstn/ddi:qstnLit elements, then FT is not used for the OR query. It is if I use AND (and of course returns an empty list as there is no match).
Many thanks as always for your assistance.
best *P
On 11/26/11 10:54 PM, Christian Grün wrote:
Hi Pascal,
The following leverages full text indexes: [...] But if I change the condition to an OR instead of AND: [...] the query no longer benefits form FT indexes
This is indeed surprising, as AND/OR shouldn't make a difference. It might be, however, that the AND expression is split into several predicates, and one of the resulting predicates is then optimized.
You could try to add an explicit .../text() location step to the paths:
...[ddi:labl/text() contains text {$text} or ddi:qstn/text() contains text {$text}]
If that doesn't help as well, feel free to provide with some small sample data.
PS: btw, let me know if you want a test database for these queries. The one I typically use is around 500Gb so would be great if you have an FTP server I could upload to.
Sounds interesting; I may get back to you soon. Christian