Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id D20E12E0080 for ; Tue, 17 Jun 2008 06:56:18 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 59139-06 for ; Tue, 17 Jun 2008 06:56:11 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ds528.dedicated.turbodns.co.uk (ds528.dedicated.turbodns.co.uk [81.21.72.118]) by developer.postgresql.org (Postfix) with ESMTP id 8BCB22E0083 for ; Tue, 17 Jun 2008 06:56:14 -0300 (ADT) Received: (qmail 92292 invoked from network); 17 Jun 2008 09:56:11 -0000 Received: from howardnews@selestial.com by ds528.dedicated.turbodns.co.uk by uid 1005 with qmail-scanner-1.22 ( Clear:RC:1(62.3.231.11):. Processed in 0.297845 secs); 17 Jun 2008 09:56:11 -0000 Received: from unknown (HELO ?10.202.6.101?) (selestial-howard.cole@62.3.231.11) by ds528.dedicated.turbodns.co.uk with SMTP; 17 Jun 2008 09:56:10 -0000 Message-ID: <485789C1.3000803@selestial.com> Date: Tue, 17 Jun 2008 10:54:09 +0100 From: Howard Cole User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Tsearch2 Initial Search Speed References: <4856A91F.1020001@selestial.com> <200806161124.57543@hal.medialogik.com> In-Reply-To: <200806161124.57543@hal.medialogik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/59 X-Sequence-Number: 30409 Alan Hodgson wrote: > It's because everything is cached, in particular the relevant rows from > the "email" table (accessing which took 22 of the original 27 seconds). > > The plan looks good for what it's doing. > > I don't see that query getting much faster unless you could add a lot more > cache RAM; 30K random IOs off disk is going to take a fair bit of time > regardless of what you do. > > Thanks Alan, I guessed that the caching was the difference, but I do not understand why there is a heap scan on the email table? The query seems to use the email_fts_index correctly, which only takes 6 seconds, why does it then need to scan the email table? Sorry If I sound a bit stupid - I am not very experienced with the analyse statement.