From: | Jules Bean <jules(at)jellybean(dot)co(dot)uk> |
---|---|
To: | Steve Heaven <steve(at)thornet(dot)co(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Performance for seq. scans |
Date: | 2000-07-26 11:28:18 |
Message-ID: | 20000726122818.A30047@grommit.office.vi.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Heaven | 2000-07-26 11:39:22 | Re: Performance for seq. scans |
Previous Message | Steve Heaven | 2000-07-26 11:14:13 | Re: Performance for seq. scans |