Re: Function execution costs 'n all that - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Function execution costs 'n all that
Date
Msg-id 27442.1170036932@sss.pgh.pa.us
Whole thread Raw
In response to Re: Function execution costs 'n all that  (Mark Dilger <pgsql@markdilger.com>)
Responses Re: Function execution costs 'n all that  (Mark Dilger <pgsql@markdilger.com>)
List 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 by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Function execution costs 'n all that
Next
From: Mark Dilger
Date:
Subject: Re: Function execution costs 'n all that