Message-ID: <485797D4.7010201@selestial.com>
Date: Tue, 17 Jun 2008 11:54:12 +0100
From: Howard Cole <howardnews@selestial.com>
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>
	<485789C1.3000803@selestial.com>
In-Reply-To: <485789C1.3000803@selestial.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I think I may have answered my own question partially, the problem may 
be how I structure the query.

I always structured my tsearch queries as follows following my initial 
read of the tsearch2 instructions...

select email_id from email, to_tsquery('default', 'howard') as q where 
q@@fts;

However if I construct them in the following way, as stipulated in the 
8.3 documentation....

select email_id from email where fts@@to_tsquery('default','howard')

Then the results are better due to the fact that the email table is not 
necessarily scanned as can be seen from the two analyse statements:

Original statement:

"Nested Loop  (cost=4.40..65.08 rows=16 width=8)"
"  ->  Function Scan on q  (cost=0.00..0.01 rows=1 width=32)"
"  ->  Bitmap Heap Scan on email  (cost=4.40..64.87 rows=16 width=489)"
"        Filter: (email.fts @@ q.q)"
"        ->  Bitmap Index Scan on email_fts_index  (cost=0.00..4.40 
rows=16 width=0)"
"              Index Cond: (email.fts @@ q.q)"

Second statement:

"Bitmap Heap Scan on email  (cost=4.40..64.91 rows=16 width=8)"
"  Filter: (fts @@ '''howard'''::tsquery)"
"  ->  Bitmap Index Scan on email_fts_index  (cost=0.00..4.40 rows=16 
width=0)"
"        Index Cond: (fts @@ '''howard'''::tsquery)"

This misses out the random access of the email table, turning my 27 
second query into 6 seconds.

I guess the construction of the first statement effectively stops the 
query optimisation from working.