Re: Function execution costs 'n all that
От | Tom Lane |
---|---|
Тема | Re: Function execution costs 'n all that |
Дата | |
Msg-id | 27442.1170036932@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Function execution costs 'n all that (Mark Dilger <pgsql@markdilger.com>) |
Ответы |
Re: Function execution costs 'n all that
|
Список | pgsql-hackers |
Mark Dilger <pgsql@markdilger.com> writes: > Tom Lane wrote: >> Would a simple constant value be workable, or do we need some more >> complex model (and if so what)? > Consider: > ANALYZE myfunc(integer) ON (SELECT myfunc(7)) WITH RATIO 0.03; > ... > It seems to me that the above system would work perfectly well for > collecting the number of rows returned from a set returning function, > not just the run times. I don't really think that data collection is the bottleneck. If a constant estimate isn't good enough for you, then you need some kind of model of how the runtime or number of rows varies with the function's inputs ... and I hardly see how something like the above is likely to figure out how to fit a good model. Or at least, if you think it can, then you skipped all the interesting bits. One other point is that we already know that sampling overhead and measurement error are significant problems when trying to measure intervals on the order of one Plan-node execution. I'm afraid that would get a great deal worse if we try to use a similar approach to timing individual function calls. regards, tom lane
В списке pgsql-hackers по дате отправления: