Re: Function execution costs 'n all that
| От | Brian Hurt |
|---|---|
| Тема | Re: Function execution costs 'n all that |
| Дата | |
| Msg-id | 45ABD9EA.3060703@janestcapital.com обсуждение исходный текст |
| Ответ на | Re: Function execution costs 'n all that (Neil Conway <neilc@samurai.com>) |
| Ответы |
Re: Function execution costs 'n all that
|
| Список | pgsql-hackers |
Neil Conway wrote:<br /><blockquote cite="mid1168887288.6174.109.camel@localhost.localdomain" type="cite"><pre wrap="">OnMon, 2007-01-15 at 10:51 -0800, Richard Troy wrote: </pre><blockquote type="cite"><pre wrap="">I therefore proposethat the engine evaluate - benchmark, if you will - all functions as they are ingested, or vacuum-like at some later date (when valid data for testing may exist), and assign a cost relative to what it already knows - the built-ins, for example. </pre></blockquote><pre wrap=""> That seems pretty unworkable. It is unsafe, for one: evaluating a function may have side effects (inside or outside the database), so the DBMS cannot just invoke user-defined functions at whim. Also, the relationship between a function's arguments and its performance will often be highly complex -- it would be very difficult, not too mention computationally infeasible, to reconstruct that relationship automatically, especially without any real knowledge about the function's behavior. </pre></blockquote> Non-developer here, but we use a lot of plpgsql functions at work. And the functionswe use fall into two broad, ill-defined catagories- "expensive" functions and "cheap" functions. What I'd likeas a user is some way to tell the planner "this function is expensive- prefer plans which call this function less evenif they're otherwise more expensive" or "this function is cheap, prefer plans that are otherwise less expensive evenif they call this function more often". Precise cost estimates aren't that important, IMHO.<br /><br /> Brian<br /><br/>
В списке pgsql-hackers по дате отправления: