Nogle problemer skiller sig ud:
Overvej først at opgradere til en aktuel version af Postgres . I skrivende stund er det pg 9.6 eller pg 10 (i øjeblikket beta). Siden Pg 9.4 har der været adskillige forbedringer til GIN-indekser, det ekstra modul pg_trgm og big data generelt.
Dernæst har du brug for meget mere RAM , især en højere work_mem indstilling. Jeg kan se fra denne linje i EXPLAIN output:
Heap Blocks: exact=7625 lossy=223807
"tab" i detaljerne for en Bitmap Heap Scan (med dine specifikke tal) indikerer en dramatisk mangel på work_mem . Postgres indsamler kun blokadresser i bitmap-indeksscanningen i stedet for rækkepegere, fordi det forventes at være hurtigere med din lave work_mem indstilling (kan ikke indeholde nøjagtige adresser i RAM). Mange flere ikke-kvalificerende rækker skal filtreres i følgende Bitmap Heap Scan denne måde. Dette relaterede svar har detaljer:
Men indstil ikke work_mem også højt uden at tage hele situationen i betragtning:
Der kan andre problemer, såsom indeks- eller tabelopsvulmning eller flere konfigurationsflaskehalse. Men hvis du retter kun disse to elementer, bør forespørgslen være meget allerede hurtigere.
Har du virkelig brug for at hente alle 40k rækker i eksemplet? Du vil sandsynligvis tilføje en lille LIMIT til forespørgslen og gør den til en "nærmeste nabo"-søgning - i så fald er et GiST-indeks trods alt det bedre valg, fordi det formodes at være hurtigere med et GiST-indeks. Eksempel: