[alanpeixinho]

What it is

The hardware details summary query matched a board with an OR across environment_misc ->> 'platform' and environment_compatible. With no test origin selected, Postgres scans tests by start_time. On bcm2711-rpi-4-b over the default 5-day window that scan read about 790,000 pages and the summary took about 40 seconds.

The query now collects the matching test ids first. One side of the UNION uses the platform index, the other the compatible index. Both summary halves keep the existing checkout, origin, lab, and duration filters, and restrict tests to those ids. The same request returns the same 262 rows in about 5 seconds.

How to test

1. Open a hardware details page with the default 5-day window and no test origin. bcm2711-rpi-4-b is a good case.
2. Confirm the summary request returns and the build, boot, and test counts match production for that board and window.
3. Repeat with a test origin selected, and with a boot duration filter. Counts should follow the filters, and the summary should stay near a few seconds.
4. In the summary SQL, confirm there is no OR between the platform field and environment_compatible.

Part of #2035.

Made with Cursor

[felipebergamin]

Comments are on the changed lines.

[felipebergamin]

The same OR of environment_misc ->> 'platform' and environment_compatible is still in query_records, query_build_records, get_hardware_listing_data_bulk, and get_hardware_summary_data. Those queries still scan tests by start_time. Share this UNION from a helper and use it in those four functions too.

[alanpeixinho]

Suggest leaving these four out of this PR.

query_records and query_build_records look like they already use both indexes: a BitmapOr of tests_platform_idx and tests_environment_compatible. On a local copy, bcm2711-rpi-4-b over 5 days (182 checkouts, 88,223 tests) was 905 ms and 1.8 s. Reusing the summary CTE there looked slower for query_records (15.6 s), because it resolves the ids and then fetches all 88,223 again.

get_hardware_listing_data_bulk and get_hardware_summary_data do seem to scan the window by start_time, since they match a VALUES list. The summary CTE would not drop in: it keys off one platform, these key off a list. A per-key lookup over 7 days:

query	keys	now	lookup
listing	2	98 s	31 s
listing	25 signup boards	60 s	13 s
failed tests	2	31 s	33 s

The 31 s listing lookup includes environment_compatible. The 13 s and 33 s ones are environment_misc only. The failed-test query looks unchanged. Both run in the weekly notification command, so the listing might be worth a separate issue.