Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WcUNv-0006RO-06 for pgsql-performance@arkaria.postgresql.org; Tue, 22 Apr 2014 06:40:51 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WcUNt-0003hl-Tj for pgsql-performance@arkaria.postgresql.org; Tue, 22 Apr 2014 06:40:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WcUNs-0003hd-Oh for pgsql-performance@postgresql.org; Tue, 22 Apr 2014 06:40:48 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WcUNn-0001Ms-Lv for pgsql-performance@postgresql.org; Tue, 22 Apr 2014 06:40:47 +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 DD3F8287A0; Mon, 21 Apr 2014 23:40:39 -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 DB92140F6A; Mon, 21 Apr 2014 23:40:39 -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 7C4E012002A; Mon, 21 Apr 2014 23:40:31 -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; Mon, 21 Apr 2014 23:40:30 -0700 (PDT) Message-ID: <53560EE5.3080300@vmware.com> Date: Tue, 22 Apr 2014 09:40:37 +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: Ivan Voras , postgres performance list Subject: Re: tsearch2, large data and indexes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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/20/2014 02:15 AM, Ivan Voras wrote: > Hello, > > If a table contains simple fields as well as large (hundreds of KiB) > text fields, will accessing only the simple fields cause the entire > record data, including the large fields, to be read and unpacked? > (e.g. SELECT int_field FROM table_with_large_text) No. > More details: after thinking about it some more, it might have > something to do with tsearch2 and indexes: the large data in this case > is a tsvector, indexed with GIN, and the query plan involves a > re-check condition. > > The query is of the form: > SELECT simple_fields FROM table WHERE fts @@ to_tsquery('...'). > > Does the "re-check condition" mean that the original tsvector data is > always read from the table in addition to the index? Yes, if the re-check condition involves the fts column. I don't see why you would have a re-check condition with a query like that, though. Are there some other WHERE-conditions that you didn't show us? The large fields are stored in the toast table. You can check if the toast table is accessed with a query like this: select * from pg_stat_all_tables where relid = (select reltoastrelid from pg_class where relname='table'); Run that before and after your query, and see if the numbers change. - Heikki -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance