Re: Performance for seq. scans - Mailing list pgsql-general

From Jules Bean
Subject Re: Performance for seq. scans
Date
Msg-id 20000726122818.A30047@grommit.office.vi.net
Whole thread Raw
In response to Re: Performance for seq. scans  (Steve Heaven <steve@thornet.co.uk>)
Responses Re: Performance for seq. scans  (Steve Heaven <steve@thornet.co.uk>)
Re: Performance for seq. scans  (bmccoy@chapelperilous.net)
Re: Performance for seq. scans  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
On Wed, Jul 26, 2000 at 12:14:13PM +0100, Steve Heaven wrote:
> At 11:51 26/07/00 +0100, you wrote:
> >Hi all,
> >
> >I've had a look over the docs and the FAQ and I can't see anything
> >answering this, so here goes:
> >
> >I'm in the (slightly unusual, in a relational world) situation that
> >the dominant query on my database is a wildcard search, so that no
> >indexes can be used.  (E.g. select * from table_a where foo like
> >'%bar%').
>
> We were in a similar position and went for the 'Full Text Indexing" extra.
> You'll find it in contrib/fulltextindex.
> It creates a function which you call on a trigger to produce an index of
> words for specified fields. These indexes do get _very_ large (one of ours
> is ~800 MB), but it does work very well and speeds searches up enormously.

If I understand you correctly, that's word-based? It's just splitting
on whitespace and punctuation?  Unfortunately, that's not quite what
we need --- our wildcard searches needn't have their '%' on word
boundaries.

Jules

pgsql-general by date:

Previous
From: Steve Heaven
Date:
Subject: Re: Performance for seq. scans
Next
From: Steve Heaven
Date:
Subject: Re: Performance for seq. scans