mirror of
https://github.com/open-metadata/OpenMetadata
synced 2026-05-24 09:39:11 +00:00
b118a87df2
* Add text_pattern_ops index on entity-table fqnHash for Postgres listings Service-filtered listings (`?service=` / `?database=` / `?databaseSchema=` / `?parent=` / `?apiCollection=` / `?spreadsheet=` / `?testSuite=`) compile to `<table>.fqnHash LIKE 'prefix%'` via ListFilter.getFqnPrefixCondition. The unique B-tree on `fqnHash` uses default `text_ops` opclass and the column inherits the database default collation (`en_US.UTF-8` on managed Postgres / RDS), neither of which lets the planner satisfy LIKE prefix from the index. Cold count(*) and the page query both fall back to a parallel seq scan over the JSONB heap — measured at ~3s on a ~580k-row storage_container_entity even after VACUUM/ANALYZE tuning and an RDS upsize. The unfiltered listing (`?limit=15`) clears the same dataset in ~215ms because it uses `idx_storage_container_entity_deleted_name_id` from 1.8.2, which the LIKE predicate cannot. Append a `text_pattern_ops` partial index on `fqnHash` for every entity table that hits getFqnPrefixCondition (24 tables: chart_entity through worksheet_entity). The `text_pattern_ops` opclass supports LIKE prefix regardless of column collation, switching the cold count(*) plan from parallel seq scan to bitmap index scan. MySQL is unaffected: every entity-table `fqnHash` column already ships with `CHARACTER SET ascii COLLATE ascii_bin`, a binary collation that lets the existing unique B-tree answer LIKE prefix predicates directly. The MySQL counterpart gets a documentation-only comment explaining the asymmetry so the next migration audit doesn't have to re-derive it. |
||
|---|---|---|
| .. | ||
| migrations | ||
| schema | ||