You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide a storage-optimized config option to avoid writing unused data to our hfj_spidx* index tables.
The tables that store indexing data (hfj_spidx_string, hfj_spidx_token, etc.) use a hashing strategy to combine the name of the search parameter (sp_name), the resource type (res_type) and represent them as a single 8 byte hash_identity value. The actual sp_name and res_type columns are never used by any queries. Combined with the sp_updated timestamp, represent 20-100 bytes of operationally unused storage for every index entry.
Acceptance Criteria
When the new storage-optimized indexing flag is on, the sp_name, res_type, and sp_updated columns should be empty.
All queries should still work.
Solution Design
Add a new config item StorageSettings - index-storage-optimized.
Migration to make the columns nullable.
When active, null sp_name, res_type and sp_updated when saving index rows.
Ensure that the index-row reuse only used the hash_exact for equality check.
Ensure that reindex still works.
Testing
Setup HAPI-FHIR server with default settings.
Create some resources with strings and identifiers. E.g. Patient with family name and identifier.
Verify that the database rows in hfj_spidx_string and hfj_spidx_token for that res_id have values in sp_name, res_type, and sp_updated.
Turn the new setting on.
Create another Patient with family name and identifier.
Verify that the database rows hfj_spidx_string and hfj_spidx_token for that res_id have null for sp_name, res_type, and sp_updated.
Run $reindex for the first Patient created (Patient/[id]/$reindex).
Verify that the rows from early now have null values for sp_name, res_type, and sp_updated.
Ensure that search still works for all values.
The text was updated successfully, but these errors were encountered:
Provide a storage-optimized config option to avoid writing unused data to our hfj_spidx* index tables.
The tables that store indexing data (
hfj_spidx_string
,hfj_spidx_token
, etc.) use a hashing strategy to combine the name of the search parameter (sp_name), the resource type (res_type) and represent them as a single 8 byte hash_identity value. The actual sp_name and res_type columns are never used by any queries. Combined with the sp_updated timestamp, represent 20-100 bytes of operationally unused storage for every index entry.Acceptance Criteria
Solution Design
Testing
hfj_spidx_string
andhfj_spidx_token
for that res_id have values in sp_name, res_type, and sp_updated.hfj_spidx_string
andhfj_spidx_token
for that res_id have null for sp_name, res_type, and sp_updated.$reindex
for the first Patient created (Patient/[id]/$reindex).The text was updated successfully, but these errors were encountered: