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).
The plan looks good for what it's doing.
I don't see that query getting much faster unless you could add a lot more
cache RAM; 30K random IOs off disk is going to take a fair bit of time
regardless of what you do.
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?
Sorry If I sound a bit stupid - I am not very experienced with the
analyse statement.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
