Fix lookup table tsv indexes

[codyebberson]

Fixing issue in previous migration that failed to create indexes on tsvectors.

---

ChatGPT analysis of resulting queries:

The EXPLAIN output shows the execution plan for your SQL query. This query is selecting records from the "Patient" table where certain conditions are met, and there exists at least one matching record in the "Address" table. Let's break down the key components of this execution plan:

1. Limit: The query starts with a LIMIT 21, which means it will only retrieve the first 21 records after sorting.

2. Sort: Before limiting the results, it sorts the data based on "Patient"."lastUpdated" in descending order. Sorting operations can be computationally expensive, especially if the dataset is large.

3. Nested Loop: The query uses a nested loop join to combine records from "Patient" and "Address" tables. This method is generally efficient for queries where one of the tables returns a small set of rows.

4. HashAggregate: This step is part of processing the EXISTS subquery. It aggregates the results from the "Address" table, grouping by "resourceId". This ensures that duplicate "resourceId" values from the "Address" table are consolidated.

5. Bitmap Heap Scan on "Address": The plan scans the "Address" table using a bitmap heap scan, which is efficient for queries that retrieve a moderate number of rows. It's filtering based on the text search condition (to_tsvector('simple',"Address"."state") @@ to_tsquery('simple','CA:*')).

6. Bitmap Index Scan on "Address_state_idx_tsv": This indicates that the query is using an index specifically designed for full-text search on the "state" column of the "Address" table. This helps in efficiently finding rows that match the text search criteria.

7. Index Scan using "Patient_pkey": After identifying the relevant "resourceId" values from the "Address" table, the query then performs an index scan on the "Patient" table using its primary key. The conditions in the WHERE clause are applied to filter the results.

Performance Insights

• Index Utilization: The query efficiently utilizes indexes, specifically a full-text search index on "Address"."state" and a primary key index on "Patient".

• Sorting Overhead: Sorting the results by "Patient"."lastUpdated" could be expensive, especially if this column is not indexed. Consider adding an index on "Patient"."lastUpdated" if the performance is not optimal.

• Nested Loop Efficiency: The nested loop join is efficient in this context because the EXISTS subquery likely limits the number of rows that need to be joined.

• Cost Estimates: The cost estimates (2411.21..2411.26 for the limit and 2411.21..2411.81 for the sort) indicate that the database expects the operation to be reasonably efficient, given the conditions and data size.

• Full-Text Search: The use of full-text search (to_tsvector and to_tsquery) suggests that the query might be sensitive to how the text data is indexed and stored.

Overall, the query seems well-optimized, especially with the use of appropriate indexes. However, actual performance should be tested with real data, as execution plans can vary based on data size, distribution, and database configuration.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

3 Ignored Deployments

Name	Status	Preview	Updated (UTC)
medplum-app	⬜️ Ignored (Inspect)		Jan 29, 2024 9:09pm
medplum-storybook	⬜️ Ignored (Inspect)		Jan 29, 2024 9:09pm
medplum-www	⬜️ Ignored (Inspect)		Jan 29, 2024 9:09pm

[github-actions]

	Messages
📖	@medplum/core: 153.9 kB
📖	@medplum/react: 338.4 kB

Generated by 🚫 dangerJS against a578e1c

[sonarcloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud