Summary
SELECT * FROM eql_v2.sort_compare(...) shows as a plain Function Scan in EXPLAIN — Postgres doesn't surface plans for EXECUTEd dynamic SQL inside PL/pgSQL bodies. So we can't tell from EXPLAIN alone whether the inner query uses indexes or seq scan.
Hypothesis
Once #183 (cross-type opfamily registration) lands, sort_compare's inner queries will inherit Index Scan behaviour automatically — the dynamic SQL goes through the same operator surface. This issue exists to verify that hypothesis once #183 is in.
Approach
- Set
auto_explain.log_nested_statements = on in the test container, run a representative sort_compare(...) invocation, capture the inner plan from the log.
- Or: instrument
eql_v2.sort_compare to RAISE NOTICE the constructed query (just for debugging during the investigation, then revert).
- Document the inner plan shape in a follow-up note here. If it's already using the index post-cipherstash/encrypt-query-language#183, close. If not, file a sub-issue.
Why this matters
sort_compare is the documented user-facing ordering helper that accepts an arbitrary WHERE filter. Any failure mode in the underlying operator resolution shows up here too, but invisibly — so we have no automated regression coverage for it today.
Summary
SELECT * FROM eql_v2.sort_compare(...)shows as a plainFunction ScaninEXPLAIN— Postgres doesn't surface plans forEXECUTEd dynamic SQL inside PL/pgSQL bodies. So we can't tell fromEXPLAINalone whether the inner query uses indexes or seq scan.Hypothesis
Once #183 (cross-type opfamily registration) lands,
sort_compare's inner queries will inherit Index Scan behaviour automatically — the dynamic SQL goes through the same operator surface. This issue exists to verify that hypothesis once #183 is in.Approach
auto_explain.log_nested_statements = onin the test container, run a representativesort_compare(...)invocation, capture the inner plan from the log.eql_v2.sort_comparetoRAISE NOTICEthe constructed query (just for debugging during the investigation, then revert).Why this matters
sort_compareis the documented user-facing ordering helper that accepts an arbitraryWHEREfilter. Any failure mode in the underlying operator resolution shows up here too, but invisibly — so we have no automated regression coverage for it today.