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.
