search suggestions select a different index than the one that gives results

[lksfjhadfas]

Hello Everyone,

We have three indexes with each indexing different properties and they are working perfectly for normal querying. But when i use suggest query

SELECT [rep:suggest()] as suggestion FROM [nt:base] as s WHERE (ISDESCENDANTNODE(s,'/content/fai/us-products')) AND suggest('richard')

It selects another index which doesnt give any results. (It selects faiLiteratureIndex rather than faiManagerIndex).

Is there any way i can rank them?

cost for [/content/fai/oak:index/faiLiteratureIndex] of type (lucene-property) with plan [lucene:faiLiteratureIndex(/content/fai/oak:index/faiLiteratureIndex) *:*] is 2.00

cost for [/content/fai/oak:index/faiManagerIndex] of type (lucene-property) with plan [lucene:faiManagerIndex(/content/fai/oak:index/faiManagerIndex) *:*] is 2.00

cost for [/content/fai/oak:index/faiBaseIndex] of type (lucene-property) with plan [lucene:faiBaseIndex(/content/fai/oak:index/faiBaseIndex) *:*] is 2.00

cost for lucene-property[/content/fai/oak:index/faiLiteratureIndex] is 2.0

Just for info though i have useInSuggest in all the indexes for different  properties

Thank you!

~Swetha

[Peter_Puzanovs · Accepted solution]

Dear Swetha,

Lucene indexes are calculated based on following formula:

Estimated Entry Count  - num of docs

Cost Per Execution - 0 //for local machine execution

Cost Per Entry  // Lucene index format V1 == 1.5 V2 == 1.0

Oak decides which index to use based on lowest execution cost. It  takes into account all matching indexes, it does not take into account user preference.

In this case, you are getting a 'Tie' where 2 indexes have same price. The first one get's chosen.

Please change your query, so that your preferred index get's better value, then the lower one. Alternatively, consider switching to Solr that provides much better support for both Suggestions and more indexing, search options in general. In Solr YOU decide which collection to use and how.

We are seeing OAK, now re-implement what Solr has already achieved in a really interesting way with little to no options of inspecting what's inside each index and no tools to manipulate your index on the fly. Could we not go 1 step back and borrow good ideas from Solr/Elastic and bring them to Oak lucene indexing?

Regards,

Peter

[smacdonald2008]

Excellent reply Peter!