Re: Tsearch2 Initial Search Speed
От | Howard Cole |
---|---|
Тема | Re: Tsearch2 Initial Search Speed |
Дата | |
Msg-id | 485797D4.7010201@selestial.com обсуждение исходный текст |
Ответ на | Re: Tsearch2 Initial Search Speed (Howard Cole <howardnews@selestial.com>) |
Ответы |
Re: Tsearch2 Initial Search Speed
Re: Tsearch2 Initial Search Speed |
Список | pgsql-performance |
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.
В списке pgsql-performance по дате отправления: