You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's important to know that the timeout is still a best-effort operation; it's
64
+
possible for the query to surpass the allotted timeout. There are two reasons for
65
+
this behavior:
66
+
67
+
1. Timeout checks are performed on a per-document basis. However, some query types
68
+
have a significant amount of work that must be performed *before* documents are evaluated.
69
+
This "setup" phase does not consult the timeout, and so very long setup times can cause
70
+
the overall latency to shoot past the timeout.
71
+
2. Because the time is once per document, a very long query can execute on a single
72
+
document and it won't timeout until the next document is evaluated. This also means
73
+
poorly written scripts (e.g. ones with infinite loops) will be allowed to execute
74
+
forever.
75
+
====
76
+
61
77
[[search-routing]]
62
78
==== routing
63
79
@@ -79,7 +95,7 @@ discuss it in detail in <<scale>>.
79
95
==== search_type
80
96
81
97
The default search type is `query_then_fetch` ((("query_then_fetch search type")))((("search options", "search_type")))((("search_type"))). In some cases, you might want to explicitly set the `search_type`
82
-
to `dfs_query_then_fetch` to improve the accuracy of relevance scoring:
98
+
to `dfs_query_then_fetch` to improve the accuracy of relevance scoring:
0 commit comments