a에 삽입진각 항목에 많은 키가 삽입될 가능성으로 인해 색인이 느려질 수 있습니다. 따라서 테이블에 대량 삽입하려면 GIN 인덱스를 삭제하고 대량 삽입을 마친 후 다시 생성하는 것이 좋습니다.

현재포스트그레SQL8.4, 지연된 인덱싱이 사용되므로 이 조언은 덜 필요합니다(참조섹션 61.4.1자세한 내용). 그러나 대규모 업데이트의 경우에는 색인을 삭제하고 다시 생성하는 것이 여전히 가장 좋습니다.

a를 위한 빌드 시간진색인은 다음에 매우 민감합니다.maintenance_work_mem설정; 인덱스 생성 중에 작업 메모리를 인색하는 것은 비용이 들지 않습니다.

기존 항목에 일련의 삽입 중진다음을 가진 색인빠른 업데이트활성화되면 시스템은 목록이 다음보다 커질 때마다 보류 항목 목록을 정리합니다.gin_pending_list_limit. 관찰된 응답 시간의 변동을 방지하려면 보류 목록 정리가 백그라운드에서(즉, autovacuum을 통해) 발생하도록 하는 것이 바람직합니다. 증가하면 전경 정리 작업을 피할 수 있습니다.gin_pending_list_limit또는 autovacuum을 더욱 공격적으로 만듭니다. 그러나 정리 작업의 임계값을 늘리면 전경 정리가 발생하면 시간이 더 오래 걸립니다.

gin_pending_list_limit저장 매개변수를 변경하여 개별 GIN 인덱스에 대해 재정의할 수 있으며, 이를 통해 각 GIN 인덱스는 자체 정리 임계값을 가질 수 있습니다. 예를 들어, 크게 업데이트될 수 있는 GIN 인덱스에 대해서만 임계값을 늘리고 그렇지 않은 경우에는 임계값을 줄이는 것이 가능합니다.

개발의 주요 목표진색인은 확장성이 뛰어난 전체 텍스트 검색에 대한 지원을 만드는 것이었습니다.포스트그레SQL, 전체 텍스트 검색에서 매우 많은 양의 결과가 반환되는 경우가 종종 있습니다. 더욱이 이는 쿼리에 매우 자주 사용되는 단어가 포함되어 있어 큰 결과 집합이 유용하지 않을 때 자주 발생합니다. 디스크에서 많은 튜플을 읽고 정렬하는 데 많은 시간이 걸릴 수 있으므로 이는 프로덕션에서는 허용되지 않습니다. (인덱스 검색 자체는 매우 빠릅니다.)

그러한 쿼리의 제어된 실행을 용이하게 하기 위해,진반환된 행 수에 대해 구성 가능한 소프트 상한이 있습니다.gin_fuzzy_search_limit구성 매개변수. 기본적으로 0(제한 없음을 의미)으로 설정됩니다. 0이 아닌 제한이 설정된 경우 반환된 집합은 무작위로 선택된 전체 결과 집합의 하위 집합입니다.

"부드러움"반환된 결과의 실제 개수는 쿼리 및 시스템 난수 생성기의 품질에 따라 지정된 제한과 다소 다를 수 있음을 의미합니다.

경험상 수천 단위의 값(예: 5000 - 20000)이 잘 작동합니다.