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

Поиск
Список
Период
Сортировка
От Nicolas Grilly
Тема Re: Where **not** to use PostgreSQL?
Дата
Msg-id CAG3yVS7nhkEbyBOdKy00ykNDxph5iX++8L2a+JmmNTdvztEyfg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Where **not** to use PostgreSQL?  (Chris Travers <chris.travers@gmail.com>)
Ответы Re: Where **not** to use PostgreSQL?  (Chris Travers <chris.travers@gmail.com>)
Re: Where **not** to use PostgreSQL?  (Michel Pelletier <pelletier.michel@gmail.com>)
Список pgsql-general
On Thu, Feb 28, 2019 at 1:24 PM Chris Travers <chris.travers@gmail.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.

I'd be curious to know a bit more about your experience in this regard.

Regards,

Nicolas Grilly

PS: A potential solution to the performance issue I mentioned is this PG extension: https://github.com/postgrespro/rum

В списке pgsql-general по дате отправления:

Предыдущее
От: Chris Travers
Дата:
Сообщение: Re: Where **not** to use PostgreSQL?
Следующее
От: Chris Travers
Дата:
Сообщение: Re: Where **not** to use PostgreSQL?