Re: procost for to_tsvector

I wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Tom> and some experiments of my own, but I wonder why we are only
>> Tom> thinking of to_tsvector. Isn't to_tsquery, for example, just
>> Tom> 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.

> Works for me.

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

> It's not so much "are they popular" as "do they involve parsing raw
> text". Once you've got the tsvector or tsquery, later steps are
> (I think) much more efficient.

I poked at this a bit more, and noted that:

* ts_headline() also parses input text, and is demonstrably at least as
expensive per-input-byte as to_tsvector.

* ts_match_tt() and ts_match_tq() invoke to_tsvector internally,
and thus should certainly have as great a cost.

* tsquery_rewrite_query() actually executes a SQL query given as a string,
with cost that is uncertain, but treating it as a unit-cost function is
surely completely silly. Since our default cost for PL-language functions
is 100, probably setting this one to 100 as well is a reasonable proposal.

So I think we should set procost for all of these functions to 100, as
per attached. Any objections?

regards, tom lane