Re: building tsquery directly in memory (avoid makepol) - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: building tsquery directly in memory (avoid makepol)
Date
Msg-id 4B6B1C3E.9060202@sigaev.ru
Whole thread Raw
In response to building tsquery directly in memory (avoid makepol)  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
Responses Re: building tsquery directly in memory (avoid makepol)
List pgsql-hackers
> Before doing it the trial and error way can somebody just make me an
> example?
> I'm not pretty sure about my interpretation of the comments of the
> documentation.
> TSQuery
[skipped]
Right, valcrc is computed in pushValue

> I couldn't see any place in the code where TSQuery is built in "one
> shot" in spite of using pushValue.
That because in all places we could parse rather complex structure. Simple OR-ed
query could be hardcoded as
pushValue('X')
pushValue('YY')
pushOperator(OP_OR);
pushValue('ZZZ')
pushOperator(OP_OR);

You need to call pushValue/pushOperator imagery order of polish notation.
Note, you can do another order:
pushValue('X')
pushValue('YY')
pushValue('ZZZ')
pushOperator(OP_OR);
pushOperator(OP_OR);

So, first example will produce ( X | YY ) | ZZZ, second one  X | ( YY | XXX )




>
> Another thing I'd like to know is: what is going to be preferred
> during a scan between
> 'java:1A,2B '::tsvector @@ to_tsquery('java:A | java:B');
> vs.
> 'java:1A,2B '::tsvector @@ to_tsquery('java:AB')
> ?
> they look equivalent. Are they?

Yes, but second one should be more efficient.
-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: testing cvs HEAD - HS/SR - cannot stat
Next
From: KaiGai Kohei
Date:
Subject: Re: Largeobject Access Controls (r2460)