Re: procost for to_tsvector - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: procost for to_tsvector
Date
Msg-id 87r3qzsrtu.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: procost for to_tsvector  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: procost for to_tsvector  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> In the OP, he suggested "on the order of 100".  Maybe we could just>> go with 100.
Tom> I'm OK with that in view of <87h9trs0zm.fsf@news-spur.riddles.org.uk>

Note that the results from that post suggest 100 as a bare minimum,
higher values would be quite reasonable.
Tom> and some experiments of my own, but I wonder why we are onlyTom> thinking of to_tsvector.  Isn't to_tsquery, for
example,justTom> about as expensive?  What of other text search functions?
 

Making the same change for to_tsquery and plainto_tsquery would be
reasonable; that would help with the seqscan cost for cases like
to_tsvector('config',col) @@ to_tsquery('blah') where the non-immutable
form of to_tsquery is used. It doesn't seem to have shown up as an issue
in reports so far because the common usage patterns don't tend to have
it evaluated for each row (either the immutable form is used, or the
to_tsquery is evaluated in a different from-clause item).

I don't recall seeing cases of any of the other functions figuring into
planner decisions.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: feature freeze and beta schedule
Next
From: Amit Kapila
Date:
Subject: Re: feature freeze and beta schedule