TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

96 pointsby sequence7about 2 years ago

8 comments

simonwabout 2 years ago
PostgreSQL FTS is mostly great - I wrote a tutorial on using it to build faceted search with Django a few years ago: <a href="https:&#x2F;&#x2F;simonwillison.net&#x2F;2017&#x2F;Oct&#x2F;5&#x2F;django-postgresql-faceted-search&#x2F;" rel="nofollow">https:&#x2F;&#x2F;simonwillison.net&#x2F;2017&#x2F;Oct&#x2F;5&#x2F;django-postgresql-facet...</a><p>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.<p>Most search engines use TF&#x2F;IDF or BM25 for relevance calculations, which consider the relative common-ness of terms in comparison to the rest of the corpus. PostgreSQL FTS can&#x27;t do that as far as I know.<p>SQLite&#x27;s built-in FTS CAN do relevance calculations like this! Surprising to see a feature as significant as that show up in SQLite but not in PostgreSQL.
评论 #35721720 未加载
评论 #35723546 未加载
sequence7about 2 years ago
I often see complicated search solutions implemented when PostgreSQL is just sitting there with its incredible FTS powers being ignored. To help some of the teams I&#x27;m working with get an idea of the power available to them I wrote up this two part article with a github repo for spinning up a db to follow along.
pmarreckabout 2 years ago
I use it; it is indeed awesome, although the “powerful” version of the query DSL can be intimidating (I implemented some complex-ish regex transformations to utilize it).<p>It’s fantastic having 1 less dependency though!<p>One caveat- if you migrate any field in the indexed table, you will likely have to drop and recreate all your triggers and stored procs again
poabout 2 years ago
I read these articles and am always tempted, but I&#x27;ve found they often don&#x27;t do well with Chinese, Japanese, Korean or other non-latin languages. I understand that isn&#x27;t the focus for most people but it&#x27;s very hard to find good data&#x2F;information on how to best support these languages.
评论 #35728125 未加载
评论 #35724718 未加载
koromakabout 2 years ago
I&#x27;ve had problems with performance over large data sets, maybe 1M records and a few &lt; 300 char fields per record.<p>I&#x27;ve never implemented full text search using a dedicated database so maybe 1M is too much to ask for.
评论 #35729087 未加载
nonethewiserabout 2 years ago
Great article and underlying point. Reminds me of <a href="https:&#x2F;&#x2F;www.amazingcto.com&#x2F;postgres-for-everything&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.amazingcto.com&#x2F;postgres-for-everything&#x2F;</a> which also highlights FTS by linking to this article: <a href="https:&#x2F;&#x2F;supabase.com&#x2F;blog&#x2F;postgres-full-text-search-vs-the-rest">https:&#x2F;&#x2F;supabase.com&#x2F;blog&#x2F;postgres-full-text-search-vs-the-r...</a>
leonardo2204about 2 years ago
The only problem I face is partial querying. For instance, if the user queries rus (and it does not match any lexemme) nothing returns. Any workarounds?
评论 #35723271 未加载
nbashawabout 2 years ago
The example here only covers short text fields like titles — does anyone know if it performant for full body search of long documents?
评论 #35725070 未加载
评论 #35726023 未加载
评论 #35723272 未加载