### Problem Two checkpoint blob queries pass the ancestor chain as a literal `thread_ts IN (...)` list: `Ai::DuoWorkflows::Workflow#blobs_by_thread_ts_for` and `#blobs_for_thread_ts` in `ee/app/models/ai/duo_workflows/workflow.rb`. On a long single-group workflow, planning this list takes about 87 ms, while execution takes about 0.5 ms. Planning is over 99% of the query time for a `channels=status` request. Each page of the stop-recovery walk pays about 0.08 ms of planning per ancestor checkpoint on each blob query. This costs about 87 ms at 1,139 checkpoints, and the cost grows linearly with the workflow's checkpoint count. Longer workflows go above the 100 ms guideline for query time. The description for https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258484 reports 171 ms of planning for the master page query with six channels. Found during the database review of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258484 (issue https://gitlab.com/gitlab-org/gitlab/-/work_items/631230). The parent issue is https://gitlab.com/gitlab-org/gitlab/-/work_items/630827. ### Proposal Pass a long `thread_ts` chain to the query as `thread_ts IN (SELECT unnest('{...}'::text[]))` instead of a literal list. This cuts planning to about 0.3 ms, for a total of about 2.1 ms. Keep the literal list for short chains. The `unnest` form reads the workflow's whole channel: 602 buffers against 7 for a 5-value chain. Switch to the array form only above a size threshold. Do not use it for every request. The array literal needs an array encoder. Do not build it by joining the `thread_ts` strings with commas. <details> <summary>Evidence</summary> Numbers come from Database Lab (`gitlab-production-main`, data as of 2026-09-29 04:24 UTC). Planning time against list size, workflow 8711521, `channel = 'status'`, literal `IN` list: ```plaintext 20 values: dedup index + Sort, planning 1.8 ms, execution 3.2 ms (cold) 200 values: index_22d319300b, planning 15.0 ms, execution 0.6 ms 600 values: index_22d319300b, planning 51.6 ms, execution 0.6 ms 1139 values: index_22d319300b, planning 106.4 ms (87 ms on repeat runs), execution 0.5 to 2.0 ms ``` ```sql SELECT "p_duo_workflows_checkpoint_blobs".* FROM "p_duo_workflows_checkpoint_blobs" WHERE "p_duo_workflows_checkpoint_blobs"."workflow_id" = 8711521 AND "p_duo_workflows_checkpoint_blobs"."workflow_created_at" = '2026-09-27 13:05:42.680577' AND "p_duo_workflows_checkpoint_blobs"."project_id" = 84861201 AND "p_duo_workflows_checkpoint_blobs"."channel" = 'status' AND "p_duo_workflows_checkpoint_blobs"."thread_ts" IN (… 1,139 thread_ts values …) ORDER BY "p_duo_workflows_checkpoint_blobs"."id" ASC ``` ```plaintext Before (literal IN list, warm): Index Scan using index_22d319300b on p_duo_workflows_checkpoint_blobs_20260927 p_duo_workflows_checkpoint_blobs (actual time=0.077..0.482 rows=506 loops=1) Index Cond: ((workflow_id = 8711521) AND (channel = 'status'::text)) Filter: ((workflow_created_at = '2026-09-27 13:05:42.680577+00'::timestamp with time zone) AND (project_id = 84861201) AND (thread_ts = ANY ('{...}'::text[]))) Buffers: shared hit=500 Planning Time: 87.062 ms Execution Time: 0.532 ms ``` ```plaintext After (thread_ts IN (SELECT unnest('{... 1,139 values ...}'::text[])), warm): Sort (actual time=1.672..1.701 rows=506 loops=1) Sort Key: p_duo_workflows_checkpoint_blobs.id Buffers: shared hit=598 -> Hash Join (actual time=1.031..1.455 rows=506 loops=1) Hash Cond: ((unnest('{...}'::text[])) = p_duo_workflows_checkpoint_blobs.thread_ts) -> HashAggregate (actual time=0.273..0.405 rows=1139 loops=1) -> Hash (actual time=0.754..0.755 rows=506 loops=1) -> Index Scan using p_duo_workflows_checkpoint_b_project_id_workflow_id_threa_idx33 on p_duo_workflows_checkpoint_blobs_20260927 p_duo_workflows_checkpoint_blobs (actual time=0.014..0.621 rows=506 loops=1) Index Cond: ((project_id = 84861201) AND (workflow_id = 8711521) AND (channel = 'status'::text) AND (workflow_created_at = '2026-09-27 13:05:42.680577+00'::timestamp with time zone)) Buffers: shared hit=598 Planning Time: 0.295 ms Execution Time: 1.762 ms ``` The `= ANY(ARRAY(SELECT unnest(...)))` form (InitPlan) also planned in 0.27 ms and ran in 2.6 ms. The multi-channel `IN ('status', 'ui_chat_log')` form behaves the same: 87.9 ms planning and 1.7 ms execution with the literal list, against 0.26 ms planning and 3.0 ms execution with `unnest`. Trade-off on a short chain (workflow 8714624, 5-value current group, warm): ```plaintext Literal IN list: Sort (actual time=0.020..0.021 rows=4 loops=1) -> Index Scan using p_duo_workflows_checkpoint_b_project_id_workflow_id_threa_idx33 ... (rows=4) Buffers: shared hit=7 Planning Time: 0.635 ms Execution Time: 0.034 ms IN (SELECT unnest(...)): Sort (actual time=1.286..1.287 rows=4 loops=1) -> Nested Loop Semi Join (rows=4) Rows Removed by Join Filter: 2482 -> Index Scan using p_duo_workflows_checkpoint_b_project_id_workflow_id_threa_idx33 ... (rows=499) Buffers: shared hit=602 Planning Time: 0.242 ms Execution Time: 1.310 ms ``` </details>