From: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: building tsquery directly in memory (avoid makepol) |
Date: | 2010-02-05 02:12:55 |
Message-ID: | 20100205031255.0ca275d2@dawn.webthatworks.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 04 Feb 2010 22:13:02 +0300
Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
> > 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
Anyway the structure I posted is correct, isn't it?
Is there any equivalent MACRO to POSTDATALEN, WEP_GETWEIGHT and
macro to know the memory size of a TSQuery?
I think I've seen MACRO that could help me to determine the size of
a TSQuery... but I haven't noticed anything like POSTDATALEN that
could come very handy to traverse a TSQuery.
I was thinking to skip pushValue and directly build the TSQuery in
memory since my queries have very simple structure and they are easy
to reduce...
Still it is not immediate to know the memory size in advance.
For OR queries it is easy but for AND queries I'll have to loop over
a tsvector, filter the weight according to a passed parameter and
see how many time I've to duplicate a lexeme for each weight.
eg.
tsvector_to_tsquery(
'pizza:1A,2B risotto:2C,4D barolo:5A,6C', '&', 'ACD'
);
should be turned into
pizza:A & risotto:C & risotto:D & barolo:A & barolo:C
I noticed you actually loop over the tsvector in tsvectorout to
allocate the memory for the string buffer and I was wondering if it
is really worth for my case as well.
Any good receipt in Moscow? ;)
thanks
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-02-05 02:16:46 | Re: testing cvs HEAD - HS/SR - cannot stat |
Previous Message | Fujii Masao | 2010-02-05 00:54:14 | Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION |