PostgreSQL documentation says: "Ranking can be expensive since it requires consulting the tsvector of each matching document, which can be I/O bound and therefore slow. Unfortunately, it is almost impossible to avoid since practical queries often result in large numbers of matches."
Some PostgreSQL developers are working on improving this by using indexes only to compute the ranking, but the related patches are not done yet.
What is the size of your data set (number of rows and size on disk) and the average response time?
Query: https://paste.kde.org/pcxyg0fay | Explain: https://explain.depesz.com/s/jN3V (101ms)
Sometimes queries end up even a lot faster, for example the same as above, but searching for "c plus plus", runs in this plan + runtime: https://explain.depesz.com/s/NPOc (11ms)
Last time I tried, it was on a machine with a spinning disk... It looks like I should try again with a SSD, which are a lot better with regard to random access.
Your search term is "Quassel". What happens if you search for a term that matches a lot of rows? This is the case where ts_rank is very expensive. I'd be curious to look at the explain of such a low-selectivity query.
But it looks like it could be possible to massively improve ranking performance by storing all necessary information directly in the GIN index, as proposed here:
https://wiki.postgresql.org/images/2/25/Full-text_search_in_...
