Re: procost for to_tsvector
От | Bruce Momjian |
---|---|
Тема | Re: procost for to_tsvector |
Дата | |
Msg-id | 20150501131357.GF6342@momjian.us обсуждение исходный текст |
Ответ на | Re: procost for to_tsvector (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: procost for to_tsvector
|
Список | pgsql-hackers |
On Fri, May 1, 2015 at 07:57:27AM -0400, Robert Haas wrote: > On Thu, Apr 30, 2015 at 9:34 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Wed, Mar 11, 2015 at 02:40:16PM +0000, Andrew Gierth wrote: > >> An issue that comes up regularly on IRC is that text search queries, > >> especially on relatively modest size tables or for relatively > >> non-selective words, often misplan as a seqscan based on the fact that > >> to_tsvector has procost=1. > >> > >> Clearly this cost number is ludicrous. > >> > >> Getting the right cost estimate would obviously mean taking the cost of > >> detoasting into account, but even without doing that, there's a strong > >> argument that it should be increased to at least the order of 100. > >> (With the default cpu_operator_cost that would make each to_tsvector > >> call cost 0.25.) > >> > >> (The guy I was just helping on IRC was seeing a slowdown of 100x from a > >> seqscan in a query that selected about 50 rows from about 500.) > > > > Where are we on setting increasing procost for to_tsvector? > > We're waiting for you to commit the patch. OK, I have to write the patch first, so patch attached, using the cost of 10. I assume to_tsvector() is the ony one needing changes. The patch will require a catalog bump too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Вложения
В списке pgsql-hackers по дате отправления: