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 17:58:14
Message-ID: 9916.958931894@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-sql
"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
> 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

In response to

Responses

pgsql-sql by date

Next:From: Mitch VincentDate: 2000-05-21 18:17:34
Subject: Re: Full text indexing (and errors!)
Previous:From: Tom LaneDate: 2000-05-21 17:12:34
Subject: Re: Foreign keys breaks tables permissions

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