"Mitch Vincent" <mitch@venux.net> writes:
> I have 2 tables.
> Table "applicants_resumes"
> Attribute | Type | Modifier
> -------------+---------+----------
> app_id | integer |
> resume_text | text |
> Index: resumes_oid_index
Uh, the query you show below is on "applicants" not on this table ...
is there an index on applicants' OID column?
> ... As you can see, really really slow. So I thought baout creating an index
> on 'string' in resumes_fti (makes since as this is suppose to be a full text
> index) -- Note that's not listed in the README which was very odd to
> me.
Isn't that what resume_fti_index is?
> ipa=# CREATE INDEX "rstring_fti_index" on resumes_fti(lower(string));
> FATAL 1: Memory exhausted in AllocSetAlloc()
lower(text) leaks memory, so I guess this would happen with a large
enough table :-(. There are plans afoot to improve matters in 7.1 ...
However, since fti.c lowercases everything it puts into the fti table,
I don't see a need for doing another lower() operation in the index
definition.
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?
regards, tom lane
