Lists: | pgsql-hackers |
---|
From: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
---|---|
To: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | avoid recasting text to tsvector when calculating selectivity |
Date: | 2008-07-16 20:56:55 |
Message-ID: | 487E6097.2040707@students.mimuw.edu.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
I'm about to write a oprrest function for the @@ operator. Currently @@
handles multiple cases, like tsvector @@ tsquery, text @@ tsquery,
tsquery @@ tsvector etc. The text @@ text case is for instance handled
by calling to_tsvector and plainto_tsquery on the input arguments.
For a @@ restriction function, I need to have a tsquery and a tsvector,
so in the text @@ text situation I'd end up calling plainto_tsquery
during planning, which would consequently get called again during
execution. Also, I'd need a not-so-elegant if-elsif-elsif sequence at
the beginning of the function. Is this OK/unavoidable/easly avoided?
Cheers,
Jan
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: avoid recasting text to tsvector when calculating selectivity |
Date: | 2008-07-17 05:26:52 |
Message-ID: | 14053.1216272412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> writes:
> I'm about to write a oprrest function for the @@ operator. Currently @@
> handles multiple cases, like tsvector @@ tsquery, text @@ tsquery,
> tsquery @@ tsvector etc. The text @@ text case is for instance handled
> by calling to_tsvector and plainto_tsquery on the input arguments.
> For a @@ restriction function, I need to have a tsquery and a tsvector,
> so in the text @@ text situation I'd end up calling plainto_tsquery
> during planning, which would consequently get called again during
> execution. Also, I'd need a not-so-elegant if-elsif-elsif sequence at
> the beginning of the function. Is this OK/unavoidable/easly avoided?
I'm not following your point here. Sure, there are multiple flavors of
@@, but why shouldn't they each have their own oprrest function?
regards, tom lane
From: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: avoid recasting text to tsvector when calculating selectivity |
Date: | 2008-07-17 06:27:48 |
Message-ID: | 487EE664.5050700@students.mimuw.edu.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> writes:
>> I'm about to write a oprrest function for the @@ operator. Currently @@
>> handles multiple cases, like tsvector @@ tsquery, text @@ tsquery,
>> tsquery @@ tsvector etc. The text @@ text case is for instance handled
>> by calling to_tsvector and plainto_tsquery on the input arguments.
>
>> For a @@ restriction function, I need to have a tsquery and a tsvector,
>> so in the text @@ text situation I'd end up calling plainto_tsquery
>> during planning, which would consequently get called again during
>> execution. Also, I'd need a not-so-elegant if-elsif-elsif sequence at
>> the beginning of the function. Is this OK/unavoidable/easly avoided?
>
> I'm not following your point here. Sure, there are multiple flavors of
> @@, but why shouldn't they each have their own oprrest function?
Because they'll all boil down to the same function. Suppose I have an
oprrest function for tsvector @@ tsquery. An oprrest for text @@ text
would just be:
tv = DatumGetTSVector(DirectFunctionCall1(to_tsvector, PG_GETARG_DATUM(0)));
tq = DatumGetTSQuery(DirectFunctionCall1(plainto_tsquery,
PG_GETARG_DATUM(1)));
res = DirectFunctionCall2(my_oprrest, TSVectorGetDatum(tv),
TSQueryGetDatun(tq))
...
I thought I might avoid having to call ts_tsvector and plainto_tsquery,
because the arguments need to be transformed to tsvector and tsquery
anyway during execution.
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
From: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: avoid recasting text to tsvector when calculating selectivity |
Date: | 2008-07-17 06:35:14 |
Message-ID: | 487EE822.1040205@students.mimuw.edu.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Jan Urbański wrote:
> Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>
>> writes:
>>> I'm about to write a oprrest function for the @@ operator. Currently
>>> @@ handles multiple cases, like tsvector @@ tsquery, text @@ tsquery,
>>> tsquery @@ tsvector etc. The text @@ text case is for instance
>>> handled by calling to_tsvector and plainto_tsquery on the input
>>> arguments.
>>
>>> For a @@ restriction function, I need to have a tsquery and a
>>> tsvector, so in the text @@ text situation I'd end up calling
>>> plainto_tsquery during planning, which would consequently get called
>>> again during execution. Also, I'd need a not-so-elegant
>>> if-elsif-elsif sequence at the beginning of the function. Is this
>>> OK/unavoidable/easly avoided?
>>
>> I'm not following your point here. Sure, there are multiple flavors of
>> @@, but why shouldn't they each have their own oprrest function?
>
> Because they'll all boil down to the same function. Suppose I have an
> oprrest function for tsvector @@ tsquery. An oprrest for text @@ text
> would just be:
> tv = DatumGetTSVector(DirectFunctionCall1(to_tsvector,
> PG_GETARG_DATUM(0)));
> tq = DatumGetTSQuery(DirectFunctionCall1(plainto_tsquery,
> PG_GETARG_DATUM(1)));
> res = DirectFunctionCall2(my_oprrest, TSVectorGetDatum(tv),
> TSQueryGetDatun(tq))
> ...
>
> I thought I might avoid having to call ts_tsvector and plainto_tsquery,
> because the arguments need to be transformed to tsvector and tsquery
> anyway during execution.
[thinks...]
OTOH, you often plan a query without executing it, so this doesn't make
sense. OK, please disregard that, I'm just beginning to see the depths
of my misunderstanding of the issue ;)
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin