From: Howard Cole <howardnews@selestial.com>
To: pgsql-performance@postgresql.org
Subject: Re: Tsearch2 Initial Search Speed
Date: Tue, 17 Jun 2008 10:54:09 +0100
Message-ID: <485789C1.3000803@selestial.com> (raw)
In-Reply-To: <200806161124.57543@hal.medialogik.com>
References: <4856A91F.1020001@selestial.com>
<200806161124.57543@hal.medialogik.com>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: howardnews@selestial.com
Subject: Re: Tsearch2 Initial Search Speed
In-Reply-To: <485789C1.3000803@selestial.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox