Re: Where **not** to use PostgreSQL?

From: Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Where **not** to use PostgreSQL?
Date: 2019-02-28 15:47:34
Message-ID: CACxu=vKmkKnMq3t-=1r6M5G9=xpAxhkAd-+7UxHSj+QbaarLTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Feb 28, 2019 at 4:50 AM Nicolas Grilly <nicolas(at)gardentechno(dot)com>
wrote:

> On Thu, Feb 28, 2019 at 1:24 PM Chris Travers <chris(dot)travers(at)gmail(dot)com>
> wrote:
>
>> 1. a) TB-scale full text search systems.
>> b) PostgreSQL's full text search is quite capable but not so
>> powerful that it can completely replace Lucene-based systems. So you have
>> to consider complexity vs functionality if you are tying with other data
>> that is already in PostgreSQL. Note further that my experience with at
>> least ElasticSearch is that it is easier to scale something built on
>> multiple PostgreSQL instances into the PB range than it is to scale
>> ElasticSearch into the PB range.
>> c) Solr or ElasticSearch
>>
>
> One question about your use of PostgreSQL for a TB-scale full-text search
> system: Did you order search results using ts_rank or ts_rank_cd? I'm
> asking because in my experience, PostgreSQL full-text search is extremely
> efficient, until you need ranking. It's because the indexes don't contain
> the necessary information for ranking, and because of this the heap has to
> be consulted, which implies a lot of random IO.
>
>
Check out the RUM index extension, it adds ranking information to indexes
to speed up exactly the problem you pointed out:

https://github.com/postgrespro/rum

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Frost 2019-02-28 16:04:32 Re: automated refresh of dev from prod
Previous Message Adrian Klaver 2019-02-28 15:15:31 Re: Pgbackrest Comparability issue