Re: Function execution costs 'n all that

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Function execution costs 'n all that
Дата
Msg-id 45ABB0D3.7040606@enterprisedb.com
обсуждение исходный текст
Ответ на Function execution costs 'n all that  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Function execution costs 'n all that  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Function execution costs 'n all that  (Gregory Stark <gsstark@mit.edu>)
Список pgsql-hackers
Tom Lane wrote:
> Instead, I'm thinking it might be time to re-introduce some notion of
> function execution cost into the system, and make use of that info to
> sort WHERE clauses into a reasonable execution order.  

That sounds like a straightforward idea.

> This example
> would be fixed with even a very stupid rule-of-thumb about SQL functions
> being more expensive than C functions, but if we're going to go to the
> trouble it seems like it'd be a good idea to provide a way to label
> user-defined functions with execution costs.

Agreed.

> Would a simple constant value be workable, or do we need some more
> complex model (and if so what)?

A simple constant would probably be enough. If we want anything fancier 
than that, it should be up to the author of the function to define the 
cost model as well. I'm envisioning that you could attach a custom cost 
function to a user-defined function which would return the estimated CPU 
cost. And # of rows returned for a set-returning function.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: xml type and encodings
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Function execution costs 'n all that