Hi Toke, Just to be clear and to understand. Does this mean that a query of the form author:name1 OR author:name2 OR author:name3
Is being processed like e.g. 1 query against the index with author:name1 getting 4 result Then 1 query against the index with author:name2 getting 3 result Then 1 query against the index with author:name3 getting 1 result And in the end all results are merged and i get a result of 8 ? So a query of thousand authors will be splitted into thousand single queries against the index? Do i understand this correctly? Thx for the help Faraz Am 28.11.2017 15:39 schrieb "Toke Eskildsen" <t...@kb.dk>: On Tue, 2017-11-28 at 11:07 +0100, Faraz Fallahi wrote: > I have a question regarding solr queries. > My query basically contains thousand of OR conditions for authors > (author:name1 OR author:name2 OR author:name3 OR author:name4 ...) > The execution time on my index is huge (around 15 sec). When i tag > all the associated documents with a custom field and value like > authorlist:1 and then i change my query to just search for > authorlist:1 it executes in 78 ms. How come there is such a big > difference in exec-time? Due to the nature of inverted indexes (which lies at the heart of Solr), your thousands of OR-queries means thousands of lookups, whereas your authorlist means a single lookup. Adding to this the results for each author needs to be merged with the other author-results - for authorlist the results are there directly. If your author lists are static, indexing them as you did in your test is the best solution. If they are not static, using a filter-query will ensure that they are at least cached subsequently, so that only the first call will be slow. If they are semi-static and there are not too many of them, you could do warm-up filter-queries for all the different groups so that the users does not pay the first-call penalty. This requires your filter- cache to be large enough to hold all the author lists. - Toke Eskildsen, Royal Danish Library
