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
Re: Performance for seq. scans Re: Performance for seq. scans |
Список | 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 по дате отправления: