Re: tsearch2, large data and indexes

From: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Ivan Voras <ivoras(at)freebsd(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: tsearch2, large data and indexes
Date: 2014-04-24 19:27:06
Message-ID: CAL_0b1sNADAoTgFOw6Zsb6+vuEbqHcu10pXQi7skQwiYdj5UtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Apr 24, 2014 at 4:34 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)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(dot)ru(at)gmail(dot)com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jonatan Evald Buus 2014-04-24 19:42:41 Poor performance for delete query
Previous Message Ivan Voras 2014-04-24 12:34:04 Re: tsearch2, large data and indexes