Re: tsearch2, large data and indexes

Поиск
Список
Период
Сортировка
От Sergey Konoplev
Тема Re: tsearch2, large data and indexes
Дата
Msg-id CAL_0b1sNADAoTgFOw6Zsb6+vuEbqHcu10pXQi7skQwiYdj5UtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tsearch2, large data and indexes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-performance
On Thu, Apr 24, 2014 at 4:34 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 04/24/2014 01:56 AM, Sergey Konoplev wrote:
>> My guess is that you could use strip() function [1] to get rid of
>> weights in your table or, that would probably be better, in your index
>> only by using expressions in it and in the query, eg.
>
> As the docs say, the GIN index does not store the weights. As such, there is
> no need to strip them. A recheck would be necessary if your query needs the
> weights, precisely because the weights are not included in the index.
>
> (In the OP's query, it's the ranking that was causing the detoasting.)

strip() is needed in the index because without it the index expression
wont match one that is in the WHERE block, and the index wont be used.
This way we could probably get rid of the "involves weights" thing,
that causes to "recheck condition", if I interpret the docs correct.

ts_rank(), for its turn, is supposed to be used in the higher node of
the plan, so there is no way for it to affect the query somehow.

But, again, it is just my guess, and it requires testing.

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray.ru@gmail.com


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

Предыдущее
От: Ivan Voras
Дата:
Сообщение: Re: tsearch2, large data and indexes
Следующее
От: Jonatan Evald Buus
Дата:
Сообщение: Poor performance for delete query