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
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 |