-
Couldn't load subscription status.
- Fork 25.6k
ST_GEOHEX fix for excessive object creation in bounded grids #130343
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
ST_GEOHEX fix for excessive object creation in bounded grids #130343
Conversation
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
|
Hi @craigtaverner, I've created a changelog YAML for you. |
|
|
||
| public GeoHashBoundedGrid(int precision, GeoBoundingBox bbox) { | ||
| private GeoHashBoundedGrid(int precision, GeoBoundingBox bbox) { | ||
| this.precision = checkPrecisionRange(precision); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be removed since it is checked in the factory earlier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Also fix an issue around nulls for out-of-bounds results And investigate and affirm that the use of -1 internally to mark invalid grid-ids is fine for all three grid types (ie. -1 is not a valid grid-id in any of these cases, for different reasons in each).
…#130343) Use new objects per thread instead of per record * Expand tests to use random bounds, after multi-thread fix * Also fix an issue around nulls for out-of-bounds results * And investigate and affirm that the use of -1 internally to mark invalid grid-ids is fine for all three grid types (ie. -1 is not a valid grid-id in any of these cases, for different reasons in each).
The PR at #125143 was creating a new object per record for bounded geo-hex grids, due to failures on serverless that appeared to be caused by race conditions in shared memory. It turns out the ES|QL evaluators already have a solution for this, so this PR fixes it to create a new object per evaluator, and the driver already ensures that each evaluator-tree is only used by either a single thread, or multiple threads in series, and never concurrently.