Re: GiST index slower than seqscan
От | CG |
---|---|
Тема | Re: GiST index slower than seqscan |
Дата | |
Msg-id | 20060421124806.49447.qmail@web37908.mail.mud.yahoo.com обсуждение исходный текст |
Ответ на | Re: GiST index slower than seqscan (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: GiST index slower than seqscan
|
Список | pgsql-general |
--- Teodor Sigaev <teodor@sigaev.ru> wrote: > > In case you're unfamiliar with this particular horse, I'm using ltree to > create > > a full text index on some <= 50 char long fields for a lookup table. The > idea > > was to be able to tear through tons of data quickly finding case > insensitive > > substring matches. > > > > Why it is a ltree, not a tsearch? When I said full text, I meant substring. Please correct me if I am wrong, but tsearch would be useful for finding words in a paragraph, not characters in a word (or small group of words) ... If I had fields 'Hello World!', 'Low Tide', and 'Following Day' they would all be hits for a search on 'low' ... > > > > Index Cond: (search_vector ~ '*.6.6.9.3.4.4.*'::lquery) > > That's the problem. Queries which begin with '*' will be slow enough... > Indeed. Substring searches are quite costly... I was hoping that the hiearchical nature of ltree would allow me to be able to sift quickly through the list since every alpha or numeric character would be a branch on the tree. > Try to reduce SIGLENINT in tsearch2/gistidx.h up to 8 (do not forget reindex > !!) > and try it.... I bet you meant ltree/ltree.h ... I'll give that a try and see what happens! Thank you! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
В списке pgsql-general по дате отправления: