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  (Mark Dilger <pgsql@markdilger.com>)
Список 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 по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: Function execution costs 'n all that
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Function execution costs 'n all that