"Mitch Vincent" <mitch(at)venux(dot)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
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
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'
regards, tom lane
In response to
pgsql-sql by date
|Next:||From: Mitch Vincent||Date: 2000-05-21 18:17:34|
|Subject: Re: Full text indexing (and errors!) |
|Previous:||From: Tom Lane||Date: 2000-05-21 17:12:34|
|Subject: Re: Foreign keys breaks tables permissions |