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

Re: Full text indexing (and errors!)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mitch Vincent" <mitch(at)venux(dot)net>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Full text indexing (and errors!)
Date: 2000-05-21 18:28:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-sql
"Mitch Vincent" <mitch(at)venux(dot)net> writes:
>> 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?

If the pattern match is reasonably selective then I'd think that the
best plan would probably be an indexscan on resumes_fti (using the
pattern operator to select rows) and then a nestloop join against the
applicant table using an inner indexscan on OID.  In English: look up
the entries in resumes_fti that match the pattern, and then use the OIDs
to look up the applicants entries ;-).  But it doesn't work without the
index on OID.

> select count(app_id) from applicants_resumes;
>  14673
> select count(id) from resumes_fti;
>  33462249

Hmm.  So the selectivity being estimated for the pattern match is
168041/33462249 or about 0.005 ... which is not huge but we'd
probably like it to be smaller.  What do you get from the standard
statistical query:

select attname,attdisbursion,s.*
from pg_statistic s, pg_attribute a, pg_class c
where starelid = c.oid and attrelid = c.oid and staattnum = attnum
and relname = 'resumes_fti';

			regards, tom lane

In response to


pgsql-sql by date

Next:From: Mitch VincentDate: 2000-05-21 19:15:46
Subject: Re: Full text indexing (and errors!)
Previous:From: Mitch VincentDate: 2000-05-21 18:17:34
Subject: Re: Full text indexing (and errors!)

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