Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WdHvE-0000bF-36 for pgsql-performance@arkaria.postgresql.org; Thu, 24 Apr 2014 11:34:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WdHvD-0002Lj-F9 for pgsql-performance@arkaria.postgresql.org; Thu, 24 Apr 2014 11:34:31 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WdHvC-0002Lb-J2 for pgsql-performance@postgresql.org; Thu, 24 Apr 2014 11:34:30 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WdHv9-0001iP-9v for pgsql-performance@postgresql.org; Thu, 24 Apr 2014 11:34:29 +0000 Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id C181528B4B; Thu, 24 Apr 2014 04:34:25 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (zcs-prod-ext-mta-1.vmware.com [10.113.62.223]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id AEF3A40F05; Thu, 24 Apr 2014 04:34:25 -0700 (PDT) Received: from zcs-prod-ext-mta-1.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTP id D69FB120030; Thu, 24 Apr 2014 04:34:25 -0700 (PDT) Received: from [192.168.1.90] (zimbra-prod-ext-proxy-vip.vmware.com [10.113.63.87]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTPSA; Thu, 24 Apr 2014 04:34:24 -0700 (PDT) Message-ID: <5358F6BE.2020104@vmware.com> Date: Thu, 24 Apr 2014 14:34:22 +0300 From: Heikki Linnakangas Organization: VMware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Sergey Konoplev , Ivan Voras CC: Jeff Janes , postgres performance list Subject: Re: tsearch2, large data and indexes References: <53560EE5.3080300@vmware.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -7.6 (-------) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 04/24/2014 01:56 AM, Sergey Konoplev wrote: > On Wed, Apr 23, 2014 at 4:08 AM, Ivan Voras wrote: >> Ok, I found out what is happening, quoting from the documentation: >> >> "GIN indexes are not lossy for standard queries, but their performance >> depends logarithmically on the number of unique words. (However, GIN >> indexes store only the words (lexemes) oftsvector values, and not >> their weight labels. Thus a table row recheck is needed when using a >> query that involves weights.)" >> >> My query doesn't have weights but the tsvector in the table has them - >> I take it this is what is meant by "involves weights." >> >> So... there's really no way for tsearch2 to produce results based on >> the index alone, without recheck? This is... limiting. > > 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.) - Heikki -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance