Re: procost for to_tsvector

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: procost for to_tsvector
Дата
Msg-id 87r3qzsrtu.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: procost for to_tsvector  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: procost for to_tsvector  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: feature freeze and beta schedule
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: feature freeze and beta schedule