Re: Full text indexing (and errors!)

"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