A form that feels slow is slow somewhere specific. Until this release the somewhere was a guess. A cursor now keeps a ledger of what it spent and where, and the three biggest spenders were cut.
Fewer statements
- Lateral joins Horizontal joins fold into keyed statements as LEFT JOIN LATERAL on Informix, PostgreSQL, MySQL and DB2, or OUTER APPLY on Oracle and SQL Server: a page of N rows with J joins costs one statement instead of one plus N times J. A first attempt folded into the main statement and took twelve minutes on a materialised Informix cursor; the fix rides laterals on keyed statements only. A kill switch exists.
- Gates in one SELECT Action gates and tab conditions evaluate as one statement, chunked at fifty expressions. An invoice form paid about 134 round trips per render before.
- Descriptions lazily Primary-key descriptions resolve one IN query per lookup table: 344 description statements per session became five on a wide-area link.
- Read-ahead sized by cadence One refresh statement per chunk at 4, 8 then 16 rows.
The ledger
- Per cost centre Build, horizontal join, batch and single refresh, row authorisation, vertical join, materialisation, parent lookup and large objects: statements, rows, total and maximum time, with the eight slowest statements kept.
- Per request Wall time with the unexplained remainder, and two warnings: large-object materialisation dominates, or the request is mostly unexplained. No parameter values and no row data recorded.
- In the client An execution panel shows the ledger beside the form.
Performance work without a ledger is anecdote. With one, each release can say what it cut.