Issue #425 Optimize spatial queries to use prepared geometries.#426
Issue #425 Optimize spatial queries to use prepared geometries.#426chrisbennight merged 1 commit intomasterfrom
Conversation
There was a problem hiding this comment.
"Interning a geometry provides no additional benefit since the geometry is already constructed in the heap at the interning begins" - I'm not quite sure the scope of the comment - do you mean interning geometries in general, interning geometries in addition to the byte[] value, etc? As I read it I disagree with this comment - or at a minimum it doesn't accurately convey the issue.
So the point of interning was to have one instance of a geometry object maintained as iterator state per JVM (or I guess classloader) instance. Since we could end up with tens of thousands of iterators per scan range a 2 MB geometry could explode into gigabytes of data, completely using up the head allocated to the tablet server.
There was a problem hiding this comment.
A geometry is constructed first prior to interning. It consumes heap space before being released to its interned duplicate. This approach prevents a Geometry from being constructed if it already exists.
I will update the comment
a81dd62 to
f3b94d9
Compare
There was a problem hiding this comment.
our formatter will change this line
There was a problem hiding this comment.
Will fix this prior to pull.
Issue #427 Zookeeper Transaction Allocator Unit Test Inconsistency
Issue #425 Optimize spatial queries to use prepared geometries.
The new approach also adds an optimization for the use of Interning geometries. The prior approach lead to excessive memory use due to the reconstitution of geometry PRIOR to interning, creating unnecessary duplicates.