Search Postgresql Archives

Re: GiST index slower than seqscan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--- Teodor Sigaev <teodor@xxxxxxxxx> 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 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux