Writing fast queries against EQL columns

This page has moved. Query and index performance for eql_v3 encrypted columns is now covered in Database Indexes for Encrypted Columns, alongside the index recipes themselves.

Getting EQL-encrypted queries competitive with plain PostgreSQL comes down to one pattern: index a functional expression over the term extractor, and let bare-form predicates engage it. The details — and the traps — live in the database-indexes guide:

• Creating indexes — the eql_v3.eq_term / ord_term / match_term recipes (no operator class on a column).
• How index engagement works — extractor inlining and structural matching.
• Range queries and the ORDER BY sort-key trap — write ORDER BY against the column's ordering extractor (eql_v3.ord_term(col) on _ord) to avoid a Sort node.
• GROUP BY / DISTINCT — group on the column's extractor, not the raw column, to stay inside work_mem (eql_v3.eq_term(col) on hm-carrying domains; eql_v3.ord_term(col) on the numeric-and-time ordering domains, which have no eq_term).
• GIN indexes for JSONB containment — public.eql_v3_json_search document search.
• Building indexes on large tables — maintenance_work_mem, btree-vs-hash build scaling, the de-TOAST floor.
• Diagnosing queries with EXPLAIN.

For which operators each domain variant supports, see the SQL support matrix.

---

Didn't find what you wanted?

Click here to let us know what was missing from our docs.