Re: Performance for seq. scans

Поиск
Список
Период
Сортировка
От Jules Bean
Тема Re: Performance for seq. scans
Дата
Msg-id 20000726122818.A30047@grommit.office.vi.net
обсуждение исходный текст
Ответ на Re: Performance for seq. scans  (Steve Heaven <steve@thornet.co.uk>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Steve Heaven
Дата:
Сообщение: Re: Performance for seq. scans
Следующее
От: Steve Heaven
Дата:
Сообщение: Re: Performance for seq. scans