Hacker News Reader

Comment by mfrye0 | Hacker News Reader

Agreed. We've been using this successfully for awhile now.

I'm curious though at what point something like this or ES itself would make sense for primarily text search. Is speed the biggest thing, or is it more flexibility to tweak and get better search results?

View on HN

Postgres is fine if your search problem is mostly a recall problem. If N is large enough or you have small N with enough overlapping keywords (long documents) then precision becomes important. That is when you need things like BM25, PageRank, machine learning, etc and Postgres just doesn't cut it anymore. Additionally spell check, high-quality autocomplete, multiple languages are better supported and much easier to implement in ES/Solr.

Postgres FTS is very basic and requires separate methods and extensions to do things like fuzzy matching. It also doesn't support modern relevance and ranking algorithms.

Search is somewhat embarrassingly parallel right? So Postgres is great until you want to shard all of your queries. Which is (of course) possible, but then you're using attributes of a tool that aren't specifically tailored to your problem space?

Postgres full text search is fast and easy, but it doesn't seem much more scaleable/reliable/resilient than a clustered search solution that is shaped to the problem at hand.

Is it fast though !?

Multi-faceted search that requires special indexing setup.

Reply on news.ycombinator.com