Re: avoid recasting text to tsvector when calculating selectivity

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
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2008-07-17 06:35:14 Re: avoid recasting text to tsvector when calculating selectivity
Previous Message David Fetter 2008-07-17 05:53:26 Re: Postgres-R source code release