On Tue, 17 Jun 2008, Howard Cole wrote:
> 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).
> 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?
It's not a sequential scan - that really would take a fair time. It's a
bitmap heap scan - that is, it has built a bitmap of the rows needed by
using the index, and now it needs to fetch all those rows from the email
table. There's 14938 of them, and they're likely scattered all over the
table, so you'll probably have to do 14938 seeks on the disc. At 5ms a
pop, that would be 70 seconds, so count yourself lucky it only takes 22
seconds instead!
If you aren't actually interested in having all 14938 rows splurged at
you, try using the LIMIT keyword at the end of the query. That would make
it run a bit faster, and would make sense if you only want to display the
first twenty on a web page or something.
Matthew
--
For every complex problem, there is a solution that is simple, neat, and wrong.
-- H. L. Mencken
