Live data from Hacker News

In PostgreSQL, powerful Full Text Search is available out of the box

admcpr.com

11–20 of 20 posts

Re: In PostgreSQL, powerful Full Text Search is available out of the box

#12
post #4

PostgreSQL FTS is mostly great - I wrote a tutorial on using it to build faceted search with Django a few years ago: https://simonwillison.net/2017/Oct/5/django-postgresql-facet... It does have one surprising limitation: it calculates relevance based on just the current row, rather than being able to take statistics across the whole corpus into account. Most search engines use TF/IDF or BM25 for relevance calculation…

> Most search engines use TF/IDF or BM25 for relevance calculations ...

Ahhh. That's what's SQLite's "bm25()" function is for.

Was white listing the SQLite FTS functions a few days ago for DBHub.io (eg so people can use them), but don't really understand (yet) how most of them are actually used. Some day I'll get around to learning about them properly. :)

Re: In PostgreSQL, powerful Full Text Search is available out of the box

#13
post #11
post #8

The example here only covers short text fields like titles — does anyone know if it performant for full body search of long documents?

Yes, it works great for that.

Depends on the length of the documents as well. I’ve used psql with smaller datasets and it’s fine, but it starts to have issues when you go bigger.

Re: In PostgreSQL, powerful Full Text Search is available out of the box

#14
post #9

I read these articles and am always tempted, but I've found they often don't do well with Chinese, Japanese, Korean or other non-latin languages. I understand that isn't the focus for most people but it's very hard to find good data/information on how to best support these languages.

There's a C++ library for tokenising Chinese for sqlite FTS: https://github.com/wangfenjin/simple

Re: In PostgreSQL, powerful Full Text Search is available out of the box

#15
post #8

The example here only covers short text fields like titles — does anyone know if it performant for full body search of long documents?

Yes, it works well but there is a limit of 16k words. See this reddit comment thread [0] for more details, but if your documents are anywhere near that big then I'd say Postgres is definitely not the right tool for you.

[0] https://www.reddit.com/r/programming/comments/12yhhcg/commen...

Re: In PostgreSQL, powerful Full Text Search is available out of the box

#16
post #8

The example here only covers short text fields like titles — does anyone know if it performant for full body search of long documents?

Yes, and if it falls short you can also use the RUM extension if you don't mind the extra index size (can install via package manager or maybe you db provider like supabase has it available)

Re: In PostgreSQL, powerful Full Text Search is available out of the box

#17
post #9

I read these articles and am always tempted, but I've found they often don't do well with Chinese, Japanese, Korean or other non-latin languages. I understand that isn't the focus for most people but it's very hard to find good data/information on how to best support these languages.

+1

I find it dishonest to call it "full text search" whereas it's actually just "English/Indo-European full text search" that uses language-specific features to achieve its goals.

Instead of pretending to have solved the string searching problem by using "language hacks", I'd really like see an open source database that provides easy to use interfaces to suffix trees instead.

The even more infuriating thing is that apparently some databases actually do have suffix tree implementations, but because of assumptions that the data is English/European, other languages work half-assedly on it.

Imagine i18n implications for projects that are based on them. And the users would have no clue how f*cked up things are.

Re: In PostgreSQL, powerful Full Text Search is available out of the box

#20
post #17
post #9

I read these articles and am always tempted, but I've found they often don't do well with Chinese, Japanese, Korean or other non-latin languages. I understand that isn't the focus for most people but it's very hard to find good data/information on how to best support these languages.

+1 I find it dishonest to call it "full text search" whereas it's actually just "English/Indo-European full text search" that uses language-specific features to achieve its goals. Instead of pretending to have solved the string searching problem by using "language hacks", I'd really like see an open source database that provides easy to use interfaces to suffix trees instead. The even more infuriating thing is that a…

With tsvector you have to declare the language, and if you are ingesting a diverse range of web documents you just end up applying English as a guess.
Post reply on HN