Text Indexing and Lookup - eXist: A NoSQL Database and Application Development Platform - page 289

If you use this configuration, the following query will return the expected Text
elements:
// Text [ ft:query (., 'index' )]
However, the following query will return nothing (i.e., an empty sequence) because
Lucene has no index on Heading elements:
// Text [ ft:query ( Heading , 'index' )]
Searching only within the contents of headings is often desirable, so you may in fact
want this to work. Luckily, nothing stops you from defining two overlapping indexes:
<lucene>
<text qname= "Text" />
<text qname= "Heading" />
</lucene>
Here is another useful example. Assume we've marked up filenames separately, as in:
<Text>
<Heading> eXist index configuration </Heading>
<Content> eXist index configuration is done in the
<Filename> collection.xconf </Filename> file </Content>
</Text>
To give the user the option to search within the full text or within either the filenames
only , we define two indexes:
<lucene>
<text qname= "Text" />
<text qname= "Filename" />
</lucene>
Now the following two queries will return the same Text element, even though the
search context for the second one is much narrower:
// Text [ ft:query (., 'collection.xconf' )]
// Text [ ft:query ( Filename , 'collection.xconf' )]
Search context and performance
Full-text indexing is an expensive operation and can have a huge impact on the per‐
formance of storing and updating documents, so use it wisely.
It's important not to define full-text indexes too broadly. For instance, a classical mis‐
take is defining your full-text indexes as:
<text match= "//*" />
This will create an index on all elements anywhere in your document. That may
sound simple and attractive, but it will cost you dearly in terms of performance.
Remember that the index is created over the text contents of a node, so an index on
the root element will index all text in the document. The same is true for all other