PostgreSQL Full-Text Search: Fast When Done Right (Debunking the Slow Myth)

Re:PostgreSQL Full-Text Search: Fast When Done Right (Debunk... by zhousun on Tuesday April 08, 2025 @09:47PM (#43628173)

Glab to see more 'postgres-native' full-text search implementation.

Alternative solutions (lucene/ tantivy) are both designed for 'immutable segments' (indexing immutable files), so marrying them with postgres heap table would results in a worse solution.

[ Parent | on HN ]

Re:PostgreSQL Full-Text Search: Fast When Done Right (Debunk... by retakeming on Wednesday April 09, 2025 @12:10AM (#43628811)

The segments themselves being immutable doesn't mean that Tantivy is incompatible with Postgres - it just means that Tantivy needs to be made compatible with Postgres' concurrency control mechanisms (MVCC) and storage format (block storage). This blog post explains the latter: https://www.paradedb.com/blog/block_storage_part_one

[ Parent | on HN ]

Re:PostgreSQL Full-Text Search: Fast When Done Right (Debunk... by sunzhousz on Wednesday April 09, 2025 @11:53AM (#43633501)

the fundamental mismatch i saw is "creating a new segment for each individual dml", it is possible to alleviate but i don't think there's a good general solution.

[ Parent | on HN ]