Skip to content

ST_EXTENT aggregation (#104659) #117451

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 58 commits into from
Dec 13, 2024
Merged

Conversation

GalLalouche
Copy link
Contributor

@GalLalouche GalLalouche commented Nov 25, 2024

Support ST_EXTENT aggregation (Issue #104659)

This PR adds support for ST_EXTENT aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). (Note the difference between this aggregation and the already implemented *scalar *function ST_EXTENT).

  • This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values.
  • We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior.

Fixes #104659

@elasticsearchmachine elasticsearchmachine added needs:triage Requires assignment of a team area label v9.0.0 labels Nov 25, 2024
@GalLalouche GalLalouche marked this pull request as draft November 25, 2024 09:57
@GalLalouche GalLalouche removed needs:triage Requires assignment of a team area label v9.0.0 labels Nov 25, 2024
@GalLalouche GalLalouche added >feature :Analytics/Geo Indexing, search aggregations of geo points and shapes Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) auto-backport Automatically create backport pull requests when merged :Analytics/ES|QL AKA ESQL labels Dec 2, 2024
* Also note that the type converting function is removed when it does not actually convert the type,
* ensuring that ReferenceAttributes are not created for the same field, and the optimization can still work.
*/
public void testSpatialTypesAndStatsExtentUseDocValues() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a test that has both centroid and extent aggregations?

Copy link
Contributor

@craigtaverner craigtaverner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I think some PhysicalPlanOptimizerTests over shapes would be good, but that can be done in the next PR where we do shape optimization.

@GalLalouche GalLalouche merged commit 2be4cd9 into elastic:main Dec 13, 2024
16 checks passed
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.x Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 117451

GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT.

This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values.
We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior.
Fixes elastic#104659.
GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT.

This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values.
We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior.
Fixes elastic#104659.
GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT.

This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values.
We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior.
Fixes elastic#104659.
GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT.

This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values.
We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior.
Fixes elastic#104659.
elasticsearchmachine pushed a commit that referenced this pull request Dec 17, 2024
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT.

This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values.
We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior.
Fixes #104659.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/ES|QL AKA ESQL :Analytics/Geo Indexing, search aggregations of geo points and shapes auto-backport Automatically create backport pull requests when merged backport pending >feature Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v8.18.0 v9.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support ST_EXTENT_AGG in ESQL
4 participants