Re: building tsquery directly in memory (avoid makepol)
От | Teodor Sigaev |
---|---|
Тема | Re: building tsquery directly in memory (avoid makepol) |
Дата | |
Msg-id | 4B6B1C3E.9060202@sigaev.ru обсуждение исходный текст |
Ответ на | building tsquery directly in memory (avoid makepol) (Ivan Sergio Borgonovo <mail@webthatworks.it>) |
Ответы |
Re: building tsquery directly in memory (avoid makepol)
|
Список | 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 по дате отправления: