Re: Full text indexing (and errors!)
От | Mitch Vincent |
---|---|
Тема | Re: Full text indexing (and errors!) |
Дата | |
Msg-id | 001c01bfc350$d6d8ddc0$0300000a@doot.org обсуждение исходный текст |
Ответ на | Full text indexing (and errors!) ("Mitch Vincent" <mitch@venux.net>) |
Ответы |
Re: Full text indexing (and errors!)
|
Список | pgsql-sql |
> 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
В списке pgsql-sql по дате отправления: