Hacker News 의견

• pg_search의 유지보수자로서, Postgres 문서에 따르면 Neon/ParadeDB 기사와 여기서 사용된 전략 모두 유효한 대안으로 제시됨

  • Postgres FTS의 문제는 단일 쿼리를 최적화하는 것이 아니라 다양한 실제 쿼리에 대해 Elastic 수준의 성능을 제공하는 것임
  • pg_search는 후자의 문제를 해결하기 위해 설계되었으며, 벤치마크도 이를 반영함
  • Neon/ParadeDB 벤치마크는 총 12개의 쿼리를 포함하며, 현실적인 사용 사례에서는 비현실적임
  • pg_search는 다양한 "Elastic 스타일" 쿼리와 Postgres 타입에 대해 간단한 인덱스 정의만으로 작동함

• tsvector를 실시간으로 계산하는 것은 큰 실수임

  • Postgres FTS를 개인 프로젝트에 구현했을 때, 문서를 읽고 지침을 따랐음
  • 문서는 기본 비최적화 사례를 만들고 최적화하는 과정을 명확히 설명함
  • 이 실수를 저지른 사람은 문서를 읽지 않았거나 Postgres FTS를 잘못 표현하려는 의도가 있는 것 같음

• 모든 것을 Postgres에 넣으려는 경향을 이해하지 못하겠음

• Postgres-native의 전체 텍스트 검색 구현을 더 많이 보게 되어 기쁨

  • 대안 솔루션(lucene/tantivy)은 불변 세그먼트에 맞춰 설계되어 Postgres 힙 테이블과 결합하면 더 나쁜 솔루션이 될 수 있음

• 설명 계획이 없어서 무슨 일이 일어나는지 이해하기 어려움

  • 쿼리가 인덱스를 사용하면 실시간 tsvector 재검사는 일치 항목에만 적용되며 벤치마크 쿼리는 LIMIT 10이므로 재검사가 적음
  • 쿼리 조건이 2개의 gin 인덱스에 조건을 가지고 있어, 계획자가 모든 일치 항목을 먼저 재검사하는 것 같음

• 몇 년 전, 네이티브 FTS를 사용하고 싶었으나 실패했음

  • 수천 개의 삽입/초가 있는 테이블에서 전체 업데이트가 느려져 트랜잭션이 시간 초과됨
  • 인덱스를 추가했으나 두 번째 인덱스가 완료되자 시스템에서 시간 초과가 발생함
  • 인덱스를 다시 삭제해야 했고, 실제 FTS 성능을 테스트할 기회를 얻지 못했음

• pg_search와 vchord_bm25 확장 RPM/DEB를 패키징했음

  • 스스로 벤치마크를 하고 싶은 사람들을 위해 링크를 제공함

• 많은 팀이 Elasticsearch나 Meilisearch로 바로 이동하는 것을 보았음

  • 적절히 사용하면 네이티브 PG FTS에서 많은 성능을 얻을 수 있음
  • SQLite + FTS5 + Wasm을 사용하여 브라우저에서 유사한 성능을 얻을 수 있을지 궁금함

• 1천만 개의 레코드는 장난감 데이터셋임

  • 전체 Wikipedia나 2022년 이전 Reddit 댓글과 같은 큰 텍스트 데이터셋이 벤치마크에 더 적합함

• 2008년경 처음으로 pg 전체 텍스트를 사용했음

  • Postgres 전체 텍스트 검색의 문제는 너무 느리다는 것이 아니라 너무 유연하지 않다는 것임
  • 간단한 검색을 추가하는 데는 좋지만 검색을 조정하려면 부족함
  • Solr와 Elasticsearch는 복잡한 인덱스와 검색 처리를 설정할 수 있음
  • Postgres는 이러한 기능을 채택할 수 있지만, 현재는 아무것도 제공하지 않음
  • Postgres는 공백을 기준으로 분할하며, 수동으로 불용어와 어간을 사용할 수 있음
  • 필드 가중치에 기반한 검색 점수 매기기가 불가능함
  • 대안과 비교했을 때 장난감 시스템임