Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TM1AQ-00072J-0u for pgsql-performance@postgresql.org; Wed, 10 Oct 2012 18:38:02 +0000 Received: from qmta14.emeryville.ca.mail.comcast.net ([2001:558:fe2d:44:76:96:27:212]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TM1AM-00088J-26 for pgsql-performance@postgresql.org; Wed, 10 Oct 2012 18:38:01 +0000 Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 9WQU1k0021bwxycAEWdwdX; Wed, 10 Oct 2012 18:37:56 +0000 Received: from mail.hathawaymix.org ([98.202.113.199]) by omta18.emeryville.ca.mail.comcast.net with comcast id 9WYv1k00E4JBJii8eWYvay; Wed, 10 Oct 2012 18:32:56 +0000 Received: from flamingo.localdomain (unknown [10.23.45.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hathawaymix.org (Postfix) with ESMTPSA id 33FF91204084; Wed, 10 Oct 2012 12:32:55 -0600 (MDT) Message-ID: <5075BF57.9010602@hathawaymix.org> Date: Wed, 10 Oct 2012 12:32:55 -0600 From: Shane Hathaway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Oleg Bartunov CC: =?ISO-8859-1?Q?Fran=E7ois_Beausoleil?= , pgsql-performance@postgresql.org Subject: Re: Ways to speed up ts_rank References: <5074996C.5020809@hathawaymix.org> <546C964C-5BE7-464D-9EC6-5FC816AEE65E@teksol.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201210/129 X-Sequence-Number: 48088 On 10/10/2012 08:59 AM, Oleg Bartunov wrote: > We'll present in Prague some improvements in FTS. Unfortunately, we have > only several minutes during lighting talk. In short, we improved GIN to > store additional information, coordinates for fts, for example and > return ordered by rank search results, which gave us performance better > than > sphynx. It's just a prototype, but we already got median at 8 msec for 6 > mln classifieds. > > We didn't tested for long documents yet. That sounds like the solution I'm looking for! Storing the info for ts_rank in an index would probably do the trick. Can I get this code somewhere? I've isolated the table I need to optimize and I can easily run tests on non-production code. Shane