Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <jesper@krogh.cc>) id 1TCAiN-0006EL-Bn
	for pgsql-performance@postgresql.org; Thu, 13 Sep 2012 14:48:23 +0000
Received: from 2605ds1-ynoe.3.fullrate.dk ([90.185.142.83]
 helo=shrek.krogh.cc)
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <jesper@krogh.cc>) id 1TCAiL-00075R-Ib
	for pgsql-performance@postgresql.org; Thu, 13 Sep 2012 14:48:22 +0000
Received: from localhost (localhost [127.0.0.1])
	by shrek.krogh.cc (Postfix) with ESMTP id 96204C44002;
	Thu, 13 Sep 2012 16:48:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at shrek.krogh.cc
Received: from shrek.krogh.cc ([127.0.0.1])
	by localhost (shrek.krogh.cc [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id TVSiIVFIPU75; Thu, 13 Sep 2012 16:48:12 +0200 (CEST)
Received: from [90.185.142.91] (2605ds1-ynoe.4.fullrate.dk [90.185.142.91])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: jesper@krogh.cc)
	by shrek.krogh.cc (Postfix) with ESMTPSA id 0C395C44001;
	Thu, 13 Sep 2012 16:48:12 +0200 (CEST)
Message-ID: <5051F227.7090600@krogh.cc>
Date: Thu, 13 Sep 2012 16:48:07 +0200
From: Jesper Krogh <jesper@krogh.cc>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bill Martin <bill.martin@communote.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Planner selects different execution plans depending
 on limit
References: 
 <D48BF41C96B16442B542F5E25C259047011E80F02A@COM211.communardo.local>
In-Reply-To: 
 <D48BF41C96B16442B542F5E25C259047011E80F02A@COM211.communardo.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201209/54
X-Sequence-Number: 47800

On 13/09/12 16:42, Bill Martin wrote:
> Yes, I've run the ANALYZE command. Regards, Bill Martin 
The main problem in your case is actually that you dont store the 
tsvector in the table.

If you store to_tsvector('simple',content.content) in a column in
the database and search against that instead
then you'll allow PG to garther statistics on the column and make the
query-planner act according to that.

Jesper