🤖 from Claude
Measured while reflowing the query demo to polygon-direct (no bbox prefilter), against the full 555,867-granule ATL03 clone with mortie 0.9.8 and an o9 footprint_cells column:
ShardMap.build(full_idx, grid9, region=ca_parts) (stored-index fast path, engaged and verified): 38.1 sCatalog.granule_records() alone over the same table: 24.9 s — shapely-parses every row's WKB into record dicts before the intersection runs- the same build on a 4,354-row bbox-cut subset: 0.32 s
So the polygon-direct query is record-materialization-bound, not morton-bound: the batched mocs_and sees arrays that already exist (values/offsets from the column), but build materializes all 555,867 granule records first and only then intersects, discarding ~99.6% of them (2,357 assigned). The stored-index plan (_footprint_cells_plan) could invert this: run the intersection on the stored arrays first, then materialize records only for rows with nonempty intersection — the polygon-direct query should land near the bbox-cut cost (~sub-second + the intersection), making the local morton query path strictly dominate a bbox prefilter.
Care points: granule_records also screens empty/non-polygonal rows (the plan's id-alignment relies on that screen's row semantics), and metadata["total_granules"] currently records records-considered — the inversion should keep both stable or document the change.
Refs #396 (the column + fast path), #400 (batch coverage); measured numbers from the demo notebook reflow session, 2026-08-16.
🤖 from Claude
Measured while reflowing the query demo to polygon-direct (no bbox prefilter), against the full 555,867-granule ATL03 clone with mortie 0.9.8 and an o9
footprint_cellscolumn:ShardMap.build(full_idx, grid9, region=ca_parts)(stored-index fast path, engaged and verified): 38.1 sCatalog.granule_records()alone over the same table: 24.9 s — shapely-parses every row's WKB into record dicts before the intersection runsSo the polygon-direct query is record-materialization-bound, not morton-bound: the batched
mocs_andsees arrays that already exist (values/offsetsfrom the column), butbuildmaterializes all 555,867 granule records first and only then intersects, discarding ~99.6% of them (2,357 assigned). The stored-index plan (_footprint_cells_plan) could invert this: run the intersection on the stored arrays first, then materialize records only for rows with nonempty intersection — the polygon-direct query should land near the bbox-cut cost (~sub-second + the intersection), making the local morton query path strictly dominate a bbox prefilter.Care points:
granule_recordsalso screens empty/non-polygonal rows (the plan's id-alignment relies on that screen's row semantics), andmetadata["total_granules"]currently records records-considered — the inversion should keep both stable or document the change.Refs #396 (the column + fast path), #400 (batch coverage); measured numbers from the demo notebook reflow session, 2026-08-16.