> Uh, the query you show below is on "applicants" not on this table ...
> is there an index on applicants' OID column?
No, there is not an index on the applicant OID column.. Since I'm getting
all the records from the applicants table where the string I search for is
in the resumes_fti table, I didn't think and index like that would help
(since I'm qualifying the results based on rows in another table). Am I
wrong in thinking that?
> Isn't that what resume_fti_index is?
Indeed, I'm a complete dork. Disregard the error below, you explained it
nicely :-)
> As far as I can tell, you're already OK on the string search, since
> you are getting an indexscan on resumes_fti. The hash join might
> not be such a bright idea though. I suspect the reason for that
> choice is the large estimate for the number of rows matched by the
> f1.string ~ '^engineer' condition (168041 which seems like a lot).
> How big are these tables really? Have you done a 'vacuum analyze'
> on them?
I have done a vacuum analyze.
select count(app_id) from applicants_resumes;
count
-------14673
(1 row)
select count(id) from resumes_fti;
count
----------33462249
(1 row)
In a word. Huge :-)
-Mitch
