Re: avoid recasting text to tsvector when calculating selectivity

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-07-17 05:35:05 Re: [COMMITTERS] pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Previous Message Abbas 2008-07-17 03:36:39 temp table problem