Indekser opprettes i @Entity klassene. Man kan se et eksempel på det i DocumentObject.java:
@Table(name = TABLE_DOCUMENT_OBJECT, indexes = @Index(name = "index_filname", columnList = "original_filename"))
Disse må hardkodes. Grunnen det ikke har vært fokus på det er fordi når vi brukte spring-data-jpa med repositories så ble de opprettet automatisk dersom det var et søk på et attributt. Senere tok vi i bruk og forkastet elasticsearch så behovet for indekser var fraværende da ES skulle ta seg av slike søk.
Støtter endring av systemID fra varchar, men det er flere klasser som må sjekkes.
Thomas
________________________________ Fra: Petter Reinholdtsen pere@hungry.com Sendt: tirsdag 11. mars 2025 10:15 Til: nikita-noark@nuug.no nikita-noark@nuug.no Emne: Re: Ytelsesobservasjoner
Jeg opprettet følgende med psql, og det ser ut til å ha redusert andelen sekvensielle søk i tabellene, om ikke annet. Målinger fra tidligere kjøring viste at spesielt bsm_base.fk_bsm_record_id fikk mange sekvensielle søk under leganto-importen.
create index bsm_base_fk_bsm_record_id_index on bsm_base USING btree(fk_bsm_record_id); create index bsm_base_fk_bsm_part_id_index on bsm_base USING btree(fk_bsm_part_id); create index bsm_base_fk_bsm_file_id_index on bsm_base USING btree(fk_bsm_file_id);
Vi får se hvor mye dette reduserer totalkjøretiden, kanskje om en ti timers tid.
Hvordan kan Nikita-koden endres slik at slike indekser opprettes av Spring?
Et annet forslag til endring som jeg ikke har kommet til å teste ennå, men som vi håper også skal gi ytelsesforbedring, er byttet til SQL-typen UUID fra varchar(36). Jeg møtte problemer med å bygge fra master, så må løse det før jeg får testet kodeendringer.
-- Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no