Merge branch 'main' into pkar/msearch-flatworld-search-project-routing

Author: pawankartik-elastic

benchmarks/src/main/java/org/elasticsearch/benchmark/_nightly/esql/QueryPlanningBenchmark.java

@@ -71,7 +71,6 @@ public class QueryPlanningBenchmark {
     }
 
     private PlanTelemetry telemetry;
-    private EsqlParser defaultParser;
     private Analyzer manyFieldsAnalyzer;
     private LogicalPlanOptimizer defaultOptimizer;
     private Configuration config;
@@ -111,7 +110,6 @@ public void setup() {
         TransportVersion minimumVersion = TransportVersion.current();
 
         telemetry = new PlanTelemetry(functionRegistry);
-        defaultParser = new EsqlParser();
         manyFieldsAnalyzer = new Analyzer(
             new AnalyzerContext(
                 config,
@@ -128,14 +126,14 @@ public void setup() {
     }
 
     private LogicalPlan plan(EsqlParser parser, Analyzer analyzer, LogicalPlanOptimizer optimizer, String query) {
-        var parsed = parser.createStatement(query, new QueryParams(), telemetry);
+        var parsed = parser.parseQuery(query, new QueryParams(), telemetry);
         var analyzed = analyzer.analyze(parsed);
         var optimized = optimizer.optimize(analyzed);
         return optimized;
     }
 
     @Benchmark
     public void manyFields(Blackhole blackhole) {
-        blackhole.consume(plan(defaultParser, manyFieldsAnalyzer, defaultOptimizer, "FROM test | LIMIT 10"));
+        blackhole.consume(plan(EsqlParser.INSTANCE, manyFieldsAnalyzer, defaultOptimizer, "FROM test | LIMIT 10"));
     }
 }

docs/changelog/138465.yaml

@@ -0,0 +1,5 @@
+pr: 138465
+summary: "Allocation: add duration and count metrics for write load hotspot"
+area: Allocation
+type: enhancement
+issues: []

docs/changelog/138492.yaml

@@ -0,0 +1,32 @@
+pr: 138492
+summary: Enable bfloat16 and on-disk rescoring for dense vectors
+area: Vector Search
+type: feature
+issues: []
+highlight:
+  title: New dense_vector options for storing bfloat16 vectors and utilising on-disk
+    rescoring
+  body: |-
+    New options have been added to the `dense_vector` field type.
+
+    The first is support for storing vectors in bfloat16 format.
+    This is a floating-point format that utilises two bytes per value rather than four, halving the storage space
+    required compared to `element_type: float`. This can be specified with `element_type: bfloat16`
+    when creating the index, for all `dense_vector` indexing types.
+
+    Float values are automatically rounded to two bytes when writing to disk, so this format can be used
+    with original source vectors at two- or four-byte precision. BFloat16 values are zero-expanded back to four-byte floats
+    when read into memory. Using `bfloat16` will cause a loss of precision compared to
+    the original vector values, as well as a small performance hit due to converting between `bfloat16` and `float`
+    when reading and writing vectors; however this may be counterbalanced by a corresponding decrease in I/O,
+    depending on your workload.
+
+    The second option is to enable on-disk rescoring. When rescoring vectors during kNN searches, the raw vectors
+    are read into memory. When the vector data is larger than the amount of available RAM, this might cause the OS
+    to evict some in-memory pages that then need to be paged back in immediately afterwards. This can cause
+    a significant slowdown in search speed. Enabling on-disk rescoring causes rescoring to use raw vector data
+    on-disk during rescoring, and to not read it into memory first. This can significantly increase search performance
+    in such low-memory situations.
+
+    Enable on-disk rescoring using the `on_disk_rescore: true` index option.
+  notable: true

docs/changelog/138726.yaml

@@ -0,0 +1,5 @@
+pr: 136624
+summary: Added Azure OpenAI chat_completion support to the Inference Plugin
+area: Machine Learning
+type: enhancement
+issues: []

docs/changelog/138776.yaml

@@ -0,0 +1,6 @@
+pr: 138776
+summary: "[Inference API] Support chunking settings for sparse embeddings in custom\
+  \ service"
+area: Machine Learning
+type: bug
+issues: []

docs/changelog/139053.yaml

@@ -0,0 +1,5 @@
+pr: 139053
+summary: Minimize doc values fetches in TSDBSyntheticIdFieldsProducer
+area: TSDB
+type: enhancement
+issues: []

docs/changelog/139075.yaml

@@ -0,0 +1,5 @@
+pr: 139075
+summary: Bump jruby/joni to 2.2.6
+area: Ingest Node
+type: enhancement
+issues: []

docs/changelog/139084.yaml

@@ -0,0 +1,5 @@
+pr: 139084
+summary: "GPU: Restrict GPU indexing to FLOAT element types"
+area: Vector Search
+type: enhancement
+issues: []

docs/reference/elasticsearch/mapping-reference/dense-vector.md

@@ -156,7 +156,7 @@ This setting is compatible with synthetic `_source`, where the entire `_source`
 
 ### Rehydration and precision
 
-When vector values are rehydrated (e.g., for reindex, recovery, or explicit `_source` requests), they are restored from their internal format. Internally, vectors are stored at float precision, so if they were originally indexed as higher-precision types (e.g., `double` or `long`), the rehydrated values will have reduced precision. This lossy representation is intended to save space while preserving search quality.
+When vector values are rehydrated (e.g., for reindex, recovery, or explicit `_source` requests), they are restored from their internal format. By default, vectors are stored at float precision, so if they were originally indexed as higher-precision types (e.g., `double` or `long`), the rehydrated values will have reduced precision. This lossy representation is intended to save space while preserving search quality. Additionally, using an `element_type` of `bfloat16` will cause a further loss in precision in restored vectors.
 
 ### Storing original vectors in `_source`
 
@@ -283,12 +283,15 @@ The following mapping parameters are accepted:
 $$$dense-vector-element-type$$$
 
 `element_type`
-:   (Optional, string) The data type used to encode vectors. The supported data types are `float` (default), `byte`, and `bit`.
+:   (Optional, string) The data type used to encode vectors.
 
 ::::{dropdown} Valid values for element_type
 `float`
 :   indexes a 4-byte floating-point value per dimension. This is the default value.
 
+`bfloat16` {applies_to}`stack: ga 9.3`
+:   indexes a 2-byte floating-point value per dimension. This uses the bfloat16 encoding, _not_ IEEE-754 float16, to maintain the same value range as 4-byte floats. Using `bfloat16` is likely to cause a loss of precision in the stored values compared to `float`.
+
 `byte`
 :   indexes a 1-byte integer value per dimension.
 
@@ -353,16 +356,16 @@ $$$dense-vector-index-options$$$
     * `int8_hnsw` - The default index type for some float vectors:
       * {applies_to}`stack: ga 9.1` Default for float vectors with less than 384 dimensions.
       * {applies_to}`stack: ga 9.0` Default for float all vectors.
-      This utilizes the [HNSW algorithm](https://arxiv.org/abs/1603.09320) in addition to automatically scalar quantization for scalable approximate kNN search with `element_type` of `float`. This can reduce the memory footprint by 4x at the cost of some accuracy. See [Automatically quantize vectors for kNN search](#dense-vector-quantization).
-    * `int4_hnsw` - This utilizes the [HNSW algorithm](https://arxiv.org/abs/1603.09320) in addition to automatically scalar quantization for scalable approximate kNN search with `element_type` of `float`. This can reduce the memory footprint by 8x at the cost of some accuracy. See [Automatically quantize vectors for kNN search](#dense-vector-quantization).
-    * `bbq_hnsw` - This utilizes the [HNSW algorithm](https://arxiv.org/abs/1603.09320) in addition to automatically binary quantization for scalable approximate kNN search with `element_type` of `float`. This can reduce the memory footprint by 32x at the cost of accuracy. See [Automatically quantize vectors for kNN search](#dense-vector-quantization).
+      This utilizes the [HNSW algorithm](https://arxiv.org/abs/1603.09320) in addition to automatically scalar quantization for scalable approximate kNN search with `element_type` of `float` or `bfloat16`. This can reduce the memory footprint by 4x at the cost of some accuracy. See [Automatically quantize vectors for kNN search](#dense-vector-quantization).
+    * `int4_hnsw` - This utilizes the [HNSW algorithm](https://arxiv.org/abs/1603.09320) in addition to automatically scalar quantization for scalable approximate kNN search with `element_type` of `float` or `bfloat16`. This can reduce the memory footprint by 8x at the cost of some accuracy. See [Automatically quantize vectors for kNN search](#dense-vector-quantization).
+    * `bbq_hnsw` - This utilizes the [HNSW algorithm](https://arxiv.org/abs/1603.09320) in addition to automatically binary quantization for scalable approximate kNN search with `element_type` of `float` or `bfloat16`. This can reduce the memory footprint by 32x at the cost of accuracy. See [Automatically quantize vectors for kNN search](#dense-vector-quantization).
 
       {applies_to}`stack: ga 9.1` `bbq_hnsw` is the default index type for float vectors with greater than or equal to 384 dimensions.
     * `flat` - This utilizes a brute-force search algorithm for exact kNN search. This supports all `element_type` values.
-    * `int8_flat` - This utilizes a brute-force search algorithm in addition to automatic scalar quantization. Only supports `element_type` of `float`.
-    * `int4_flat` - This utilizes a brute-force search algorithm in addition to automatic half-byte scalar quantization. Only supports `element_type` of `float`.
-    * `bbq_flat` - This utilizes a brute-force search algorithm in addition to automatic binary quantization. Only supports `element_type` of `float`.
-    * {applies_to}`stack: ga 9.2` `bbq_disk` - This utilizes a variant of [k-means clustering algorithm](https://en.wikipedia.org/wiki/K-means_clustering) in addition to automatic binary quantization to partition vectors and search subspaces rather than an entire graph structure as in with HNSW. Only supports `element_type` of `float`.  This combines the benefits of BBQ quantization with partitioning to further reduces the required memory overhead when compared with HNSW and can effectively be run at the smallest possible RAM and heap sizes when HNSW would otherwise cause swapping and grind to a halt.  DiskBBQ largely scales linearly with the total RAM.  And search performance is enhanced at scale as a subset of the total vector space is loaded. This requires an [Enterprise subscription](https://www.elastic.co/subscriptions).
+    * `int8_flat` - This utilizes a brute-force search algorithm in addition to automatic scalar quantization. Only supports `element_type` of `float` or `bfloat16`.
+    * `int4_flat` - This utilizes a brute-force search algorithm in addition to automatic half-byte scalar quantization. Only supports `element_type` of `float` or `bfloat16`.
+    * `bbq_flat` - This utilizes a brute-force search algorithm in addition to automatic binary quantization. Only supports `element_type` of `float` or `bfloat16`.
+    * {applies_to}`stack: ga 9.2` `bbq_disk` - This utilizes a variant of [k-means clustering algorithm](https://en.wikipedia.org/wiki/K-means_clustering) in addition to automatic binary quantization to partition vectors and search subspaces rather than an entire graph structure as in with HNSW. Only supports `element_type` of `float` or `bfloat16`.  This combines the benefits of BBQ quantization with partitioning to further reduces the required memory overhead when compared with HNSW and can effectively be run at the smallest possible RAM and heap sizes when HNSW would otherwise cause swapping and grind to a halt.  DiskBBQ largely scales linearly with the total RAM.  And search performance is enhanced at scale as a subset of the total vector space is loaded. This requires an [Enterprise subscription](https://www.elastic.co/subscriptions).
 
 `m`
 :   (Optional, integer) The number of neighbors each node will be connected to in the HNSW graph. Defaults to `16`. Only applicable to `hnsw`, `int8_hnsw`, `int4_hnsw` and `bbq_hnsw` index types.
@@ -390,6 +393,9 @@ $$$dense-vector-index-options$$$
     :   In case a knn query specifies a `rescore_vector` parameter, the query `rescore_vector` parameter will be used instead.
     :   See [oversampling and rescoring quantized vectors](docs-content://solutions/search/vector/knn.md#dense-vector-knn-search-rescoring) for details.
 :::::
+
+`on_disk_rescore` {applies_to}`stack: preview 9.3` {applies_to}`serverless: unavailable`
+:   (Optional, boolean) Only applicable to quantized HNSW and `bbq_disk` index types. When `true`, vector rescoring will read the raw vector data directly from disk, and will not copy it in memory. This can improve performance when vector data is larger than the amount of available RAM. This setting only applies to newly-indexed vectors; after changing this setting, the vectors must be reindexed or force-merged to apply the new setting to the whole index. Defaults to `false`.
 ::::