Re: Inefficient filter order in query plan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inefficient filter order in query plan
Дата
Msg-id 4827.1393527747@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inefficient filter order in query plan  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-performance
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> You could try increasing the cost attributed to the texticlike() function
>> if you don't like the results you're getting here.

> Perhaps we should be attributing some additional cost to operations
> which (are likely to) require de-TOAST'ing a bunch of values?  It's not
> obvious from the original email, but it's at least my suspicion that the
> difference is amplified due to de-TOAST'ing of the values in that text
> column, in addition to the straight-up function execution time
> differences.

Could be.  We've discussed adding some charge for touching
likely-to-be-toasted columns in the past, but nobody's done anything
about it.  Note that I'd rather see that implemented as a nonzero cost
for Vars than as a charge for functions per se.

> Costing integer (or anything that doesn't require pointer maniuplations)
> operations as cheaper than text-based operations also makes sense to me,
> even though of course there's more things happening when we do these
> comparisons than the simple CPU-level act of doing the cmp.

Right.  We've bumped up the cost numbers for some extremely expensive
functions, but I would like to have some actual data rather than just seat
of the pants guesses before we go fooling with the standard CPU cost
estimates for things at the level of regex matches.

            regards, tom lane


В списке pgsql-performance по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Inefficient filter order in query plan
Следующее
От: Tom Coogan
Дата:
Сообщение: Re: Inefficient filter order in query plan