feat(search): geohash aggregation - #3272
Draft
dschmidt wants to merge 2 commits into
Draft
Conversation
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 13 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
August 18, 2026 17:00
59aacc8 to
c775513
Compare
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 7, 2026 22:14
c775513 to
2d46411
Compare
1 task
dschmidt
added a commit
that referenced
this pull request
Sep 8, 2026
The same tokenizer with tag_depth turns a geohash into depth-tagged prefixes, so a terms facet with TermPrefix is a geohash grid at that precision. One location_geohash field per geopoint, part of the v5 schema so #3272 needs no further bump. OpenSearch maps it unindexed, geohash_grid works on the geo_point.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
1 task
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
OpenSearch buckets a geohash_grid aggregation on the geo_point itself, bleve has no such aggregation. bleve now maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into depth-tagged prefixes, so a terms facet with TermPrefix "<precision>/" is the grid at that precision (#3272). Only bleve knows the field, the shared document shape and OpenSearch are untouched; the mapping change is additive.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into depth-tagged prefixes, so a terms facet with TermPrefix "<precision>/" is a geohash grid (#3272). bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into depth-tagged prefixes, so a terms facet with TermPrefix "<precision>/" is a geohash grid (#3272). bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
1 task
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
(cherry picked from commit 0cfe3b8)
A geohash_precision aggregation runs as a terms facet on the geohash sibling of the geopoint, restricted to the terms tagged with the requested precision; nested, it folds the same terms from doc values. The cells match OpenSearch's geohash_grid, pinned in the parity suite.
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 11, 2026 14:33
2d46411 to
d7bdce8
Compare
dschmidt
changed the title
dschmidt
changed the base branch from
feat/graph-search-query
to
feat/search-bleve-geohash-sibling
September 11, 2026 14:33
dschmidt
added this pull request to stack #3520
September 11, 2026 14:34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
AggregationOption.geohash_precision(1-12) turns an aggregation on a geopoint field into a geohash grid: bucket key is the cell, value the doc count. Rejected on non-geo fields and precisions beyond 12.geohash_gridon the geopoint sibling.Stacked on #3211 and #3519. No mapping change.
How Has This Been Tested
Types of changes