mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-29 01:44:36 -04:00
eb1c490264
* Add initial structure for ST_CENTROID * Revert "Revert stab at implementing forStats for doc-values vs source" This reverts commitcfc4341bf4. * Refined csv-spect tests with st_centroid * Spotless disagrees with intellij * Fixes after reverting fieldmapper code to test GeoPointFieldMapper * Get GeoPointFieldMapperTests working again after enabling doc-values reading * Simplify after rebase on main In particular, field-mappers that do not need to know about fields can have simpler calls. * Support local physical planning of forStats attributes for spatial aggregations * Get st_centroid aggregation working on doc-values We changed it to produce BytesRef, so we don't (yet) need any doc-values types. * Create both DocValues and SourceValues versions of st_centroid * Support physical planning of DocValues and SourceValues SpatialCentroid * Improve test for physical planning of DocValues in SpatialCentroid * Fixed show functions for st_centroid * More st_centroid tests with mv_expand To test single and multi-value centroids * Fix st_centroid from point literals The blocks contained BytesRef byte[] with multiple values, and we were ignoring the offsets when decoding, so decoding the first value over and over instead of decoding the subsequent values. * Teach CsvTests to handle spatial types alternative loading from doc-values Spatial GEO_POINT and CARTESIAN_POINT load from doc-values in some cases. If the physical planner has planned for this, we need the CsvTests to also take that into account, changing the type of the point field from BytesRefBlock to LongBlock. * Fixed failing NodeSubclassTests Required making the new constructor public and enabling Set as a valid parameter in the test framework. * More complex st_centroid tests and fixed bug with multiple aggs When there were multiple agregations in the same STATS, we were inadvertently re-ordering them, causing the wrong Blocks to be fed to the wrong aggregator in the coordinator node. * Update docs/changelog/104218.yaml * Fix automatically generated changelog file * Fixed failing test The nodes can now sometimes be Set, which is also a Collection, but not a List, and therefor never can be a subset of the children. * More tests covering more combinations including MV_EXPAND and grouping * Added cartesian st_centroid with grouping test We could not add MV_EXPAND tests since the cartesian data does not have multi-value columns, but the geo_point tests are sufficient for this since they share the same code. * Reduce flaky tests by sorting results * Reduce flaky tests by sorting results * Added tests for stats on stats to ensure planner coped * Add unit tests to ensure doc-values in query planning complex cases * Some minor updates from code review * Fixes after rebase on main * Get correct error message on unsupported geo_shape for st_centroid * Refined point vs shape differences after merging main * Added basic docs * Delete docs/changelog/104218.yaml * Revert "Delete docs/changelog/104218.yaml" This reverts commit4bc596a442. * Fixed broken docs tag link * Simplify BlockReaderSupport in MapperTestCase from code review * Moved spatial aggregations into a sub-package * Added some more code review updates, including nested tests * Get nested functions working, if only from source values for now * Code review update * Code review update * Added second location column to airports for wider testing * Use second location in tests, including nulls Includes a test fix for loading and converting nulls to encoded longs. * Fixed bug supporting multi spatial aggregations in the local node The local physical planner only marked a single field for stats loading, but marked all spatial aggregations for stats loading, which load to only one aggregation getting the right data, while the rest would get the wrong data. * Renamed forStats to fieldExtractPreference for clarity Now the planner decides whether to load data from doc-values. To remove the confusion of preferDocValues==false in the non-spatial cases, we use an ENUM with the default value of NONE, to make it clear we're leaving the choice up to the field type in all non-spatial cases. * EsqlSpecIT was failing on very high precision centroids on different computers This was not reproducible on the development machine, but CI machines were sufficiently different to lead to very tiny precision changes over very large Kahan summations. We fixed this by reducing the need for precision checks in clustered integration tests. * Delete docs/changelog/104218.yaml * Revert "Delete docs/changelog/104218.yaml" This reverts commit12c6980881. * Fixed changelog entry
32 lines
757 B
Text
32 lines
757 B
Text
[[esql-agg-functions]]
|
|
==== {esql} aggregate functions
|
|
|
|
++++
|
|
<titleabbrev>Aggregate functions</titleabbrev>
|
|
++++
|
|
|
|
The <<esql-stats-by>> function supports these aggregate functions:
|
|
|
|
// tag::agg_list[]
|
|
* <<esql-agg-avg>>
|
|
* <<esql-agg-count>>
|
|
* <<esql-agg-count-distinct>>
|
|
* <<esql-agg-max>>
|
|
* <<esql-agg-median>>
|
|
* <<esql-agg-median-absolute-deviation>>
|
|
* <<esql-agg-min>>
|
|
* <<esql-agg-percentile>>
|
|
* <<esql-agg-st-centroid>>
|
|
* <<esql-agg-sum>>
|
|
// end::agg_list[]
|
|
|
|
include::avg.asciidoc[]
|
|
include::count.asciidoc[]
|
|
include::count-distinct.asciidoc[]
|
|
include::max.asciidoc[]
|
|
include::median.asciidoc[]
|
|
include::median-absolute-deviation.asciidoc[]
|
|
include::min.asciidoc[]
|
|
include::percentile.asciidoc[]
|
|
include::st_centroid.asciidoc[]
|
|
include::sum.asciidoc[]
|