Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 97F3462698C for ; Mon, 16 Apr 2012 13:19:35 -0300 (ADT) Received: from [2001:1528:137::f1] (helo=mail.gransy.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SJoeL-0005UL-4u for pgsql-performance@postgresql.org; Mon, 16 Apr 2012 16:19:35 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 44C5E5086B1 for ; Mon, 16 Apr 2012 18:19:17 +0200 (CEST) Received: from mail.gransy.com ([82.208.29.194]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id KI6ppsQe-mm4 for ; Mon, 16 Apr 2012 18:19:17 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id 32C0A5086B2; Mon, 16 Apr 2012 18:19:17 +0200 (CEST) Received: from [192.168.1.237] (ip-78-45-133-255.net.upcbroadband.cz [78.45.133.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id B53325086C3 for ; Mon, 16 Apr 2012 18:19:16 +0200 (CEST) Message-ID: <4F8C4684.5040609@fuzzy.cz> Date: Mon, 16 Apr 2012 18:19:16 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: SeqScan with full text search References: <5afd048c-19e2-4a81-8439-bc09839d29dc@n5g2000vbf.googlegroups.com> In-Reply-To: <5afd048c-19e2-4a81-8439-bc09839d29dc@n5g2000vbf.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:1528:137::f1 (failed) X-Pg-Spam-Score: -1.1 (-) X-Archive-Number: 201204/120 X-Sequence-Number: 46766 On 16.4.2012 16:02, Tomek Walkuski wrote: > Hello group! > > I have query like this: > > SELECT > employments.candidate_id AS candidate_id, > SUM(TS_RANK(employers.search_vector, TO_TSQUERY('simple', 'One:* | > Two:* | Three:* | Four:*'), 2)) AS ts_rank > FROM > employments > INNER JOIN > employers ON employments.employer_id = employers.id > AND > employers.search_vector @@ TO_TSQUERY('simple', 'One:* | Two:* | > Three:* | Four:*') > GROUP BY > candidate_id; > > And it results with this: > > http://explain.depesz.com/s/jLM > > The JOIN between employments and employers is the culprit. I'm unable > to get rid of the seq scan, and setting enable_seqscan to off makes > things even worse. > > Is there any way to get rid of this JOIN? Well, it's clearly the seqscan that takes most time, and it seems that you really need to scan the whole table because you're asking 'for each employment of all the candidates ...' So you really need to scan all 1.6 million rows to get the result. And seqscan is the best way to do that. I don't see a way to remove the join and/or seqscan, unless you want to keep a 'materialized view' maintained by a trigger or something ... Another option is to make the employment table as small as possible (e.g. removing columns that are not needed etc.) so that the seqscan is faster. > > What info should I post to debug this easier? 1) structures of the tables 2) what amount of data are we talking about 3) was this the first run (with cold caches) or have you run that several times? 4) basic system info (RAM, CPU, shared_buffers etc.) Tomas