ArcadeData#8775 was decided 2026-10-01: inside a transaction a scan stays sequential, and POST /api/v1/query and POST /api/v1/command wrap even a plain SELECT in an auto-commit transaction. Every served ArcadeDB arm in the harness reads through one of them (/query in l1_tabular, l2_graph, l3_sparse, l3d_dense, l4_tsbs; /command for l1_tpc's olap), while the embedded arms read with no transaction. Measured on a server, 1M vertices, filtered count: SQL 321-326 ms through POST against 45-47 ms through GET /query or Postgres; Cypher 333-339 ms against 44-55 ms through Bolt or GET /query.
October is unaffected: at the pin a type scan needed two bucket sub-steps to run in parallel, every type has one, and no lane changes that, so neither arm scanned in parallel. At the re-pin (26.10.1, with parallel filtered scans and single-bucket page splitting) it would make served scans sequential and embedded ones parallel. This adds the re-pin item to CAMPAIGN section 7 (row 25); the code change is for the re-pin, not now.
ArcadeData#8775 was decided 2026-10-01: inside a transaction a scan stays sequential, and
POST /api/v1/queryandPOST /api/v1/commandwrap even a plain SELECT in an auto-commit transaction. Every served ArcadeDB arm in the harness reads through one of them (/queryin l1_tabular, l2_graph, l3_sparse, l3d_dense, l4_tsbs;/commandfor l1_tpc'solap), while the embedded arms read with no transaction. Measured on a server, 1M vertices, filtered count: SQL 321-326 ms through POST against 45-47 ms through GET /query or Postgres; Cypher 333-339 ms against 44-55 ms through Bolt or GET /query.October is unaffected: at the pin a type scan needed two bucket sub-steps to run in parallel, every type has one, and no lane changes that, so neither arm scanned in parallel. At the re-pin (26.10.1, with parallel filtered scans and single-bucket page splitting) it would make served scans sequential and embedded ones parallel. This adds the re-pin item to CAMPAIGN section 7 (row 25); the code change is for the re-pin, not now.