From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Michael Nachbaur <mike(at)nachbaur(dot)com>, <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Forcing query to use an index |
Date: | 2003-03-04 01:26:59 |
Message-ID: | 877kbfj50c.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> -> Merge Join (cost=6106.42..6335.30 rows=2679 width=265)
(actual time=859.77..948.06 rows=1 loops=1)
Actually another problem, notice the big discrepancy between the estimated row
and the actual rows. That's because you have the big OR clause so postgres
figures there's a good chance one of the clauses will be true so it estimates
a lot of rows will match. In fact of course they're all very selective and
you'll usually probably only get a few records.
If you're stuck with the unanchored text search it will always do a full table
scan so it will never be lightening fast. But it would probably be a bit
faster if you put a limit clause (on a subquery) on the table that's doing the
full table scan.
That will convince postgres that there won't be thousands of resulting
records, which might convince it to do a nested loop.
Also, as a beneficial side effect will also limit the damage if one your users
does a search for "e"...
This only really helps if you can get rid of the OR CMS.package clause...
otherwise it actually needs all the records in case they match a summary
record with a kate package.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Hepworth, Mike | 2003-03-04 01:30:40 | SCHEMA's |
Previous Message | Greg Stark | 2003-03-04 01:14:11 | Re: Forcing query to use an index |