Just to clarify (for me): The proposed add'l info and streamlining
would be orthogonal to column versus row storage as the format, yes?
On 7/24/26 10:04 AM, Suryaa Charan Shivakumar wrote:
Hi everyone,
I wanted to start a discussion around columnar support for GEOMETRY,
motivated by the work in my current PR (
https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/21333). The PR itself is
fairly small, it enables GEOMETRY as a columnar type but while working on
it I realized the broader design deserves discussion first. Today, geometry
in columnar storage behaves differently from most primitive types. This
patchset focuses on enabling the columnar store for the GEOMETRY type as a
first step. While implementing it, I found that the current serialized
representation limits the performance benefits we can get from columnar
execution. It would be great if someone familiar with the columnar layer
could take a look at the patchset and help confirm whether this is the
right direction before I build further geometry-specific optimizations on
top of it.
Current flow
The current implementation stores the serialized geometry (WKB) as an
opaque byte sequence [int32 length][WKB bytes]. During query execution:
column scan -> read geometry bytes -> copy into tagged Asterix
GEOMETRY value -> deserialize into JTS Geometry -> execute spatial
function
For eg. SELECT SUM(st_n_points(g)) FROM all_nodes_col; still performs
WKB parsing, JTS object allocation, and JTS traversal for every
geometry.
Columnar storage avoids reading unrelated fields, but once g is projected,
execution follows nearly the same geometry-materialization path as row
storage. Geometry also currently uses delta byte-array encoding and does
not have a meaningful ordering, so it cannot benefit from the normal column
min/max filters.
This was visible in a PBSM benchmark. Columnar storage read roughly 72%
fewer pages than row storage, but execution was still slightly slower
because most of the runtime was spent after the scan in geometry
materialization, tiling, sorting, and exact predicate evaluation.
The goal would be to (a) add serialized-geometry fast paths for functions
that can be evaluated directly from WKB, such as st_n_points,
st_geometrytype, st_dimension, and st_isempty. The evaluator would fall
back to JTS only when direct serialized evaluation is unsupported. (b)
Store derived geometry metadata alongside the WKB payload, such as: type,
point count, empty flag, xmin, ymin, xmax, ymax. This could allow scalar
functions to avoid reading the full geometry and allow spatial joins and
predicates to use MBR metadata before JTS refinement. Note this might also
be doubling the storage for simple geometry types like point where we would
be storing more metadata than the data itself. The geometry-specific
metadata would be new to the columnar primary store, but the broader
pattern of storing derived metadata to reduce query-time work already
exists.
Existing patterns
This follows patterns used elsewhere:
-
PostGIS exposes metadata and bounding boxes from its serialized geometry
representation.
-
GeoParquet supports geometry metadata and bounding-box covering columns.
-
Sedona uses bounding-box metadata for pruning before JTS evaluation.
-
AsterixDB columnar storage already maintains auxiliary filter metadata
for other types, and spatial indexes already store derived MBR values.
