Skip site navigation (1) Skip section navigation (2)

Re: Full text indexing (and errors!)

From: "Mitch Vincent" <mitch(at)venux(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Full text indexing (and errors!)
Date: 2000-05-21 18:17:34
Message-ID: 001c01bfc350$d6d8ddc0$0300000a@doot.org (view raw or flat)
Thread:
Lists: 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







In response to

Responses

pgsql-sql by date

Next:From: Tom LaneDate: 2000-05-21 18:28:35
Subject: Re: Full text indexing (and errors!)
Previous:From: Tom LaneDate: 2000-05-21 17:58:14
Subject: Re: Full text indexing (and errors!)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group