Re: Hstore index for full text search

Поиск
Список
Период
Сортировка
От Michael Lewis
Тема Re: Hstore index for full text search
Дата
Msg-id CAHOFxGp-zFFyF+3-q30Pb1gSAdE5+3eeedUqkdetRX0jt8yPfQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hstore index for full text search  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Hstore index for full text search  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Tue, Aug 11, 2020 at 4:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
A GIN index on an hstore column only provides the ability to search for
exact matches to hstore key strings.  There are a few bells and whistles,
like the ability to AND or OR such conditions.  But basically it's just an
exact-match engine, and it doesn't index the hstore's data values at all
(which is why the implementors weren't too concerned about having a length
limit on the index entries).  There is 0 chance of this index type being
useful for what the OP wants to do.

Thanks for sharing. More like json path ops and not the full key and value. Interesting.
 
Another point is that you will only
get an indexscan if *every* OR'd clause matches some index.  The example
query looks sufficiently unstructured that that might be hard to ensure.

Does this still apply when the where clauses are on several tables and not just one?

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Hstore index for full text search
Следующее
От: Jim Jarvie
Дата:
Сообщение: Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?