Re: [Fwd: Re: Functionscan estimates]

I'm not subscribed to performance at this time. I reviewed the
thread and owe everything I know about this to Wei Hong whose
brilliance exceeds all others :) All misinterpretations are
mine alone.

I have not reviewed hellerstein's papers posted by neil, but I
will.

My understanding of this issue is at a very high user level.
In Illustra SRF functions were not necessarily special functions.
All functions could have a cost associated with them, set by the writer of
the function in order for the planner to reorder function calls.
The stonebraker airplane level example was:
select ... from ... where f(id) = 3 and expensive_image_function(img)
The idea, of course is to weight the expensive function so it was
pushed to the end of the execution.

The only difference I see with SRFs in Postgres is that you may want
the cost represented as one row returned and another weighting representing
the number of estimated rows. I think this conclusion has already
been drawn.

It seems to make sense, if the optimizer can use this information, to
include wild and/or educated guesses for the costs of the SRF.

I'm sure I haven't contributed here anything new, but perhaps
phrased it differently.

Copy me on replies and I'll participate as I can.

--elein

On Thu, Apr 14, 2005 at 08:36:38AM +0100, Simon Riggs wrote:
> Elein,
>
> Any chance you could join this discussion on PERFORM ?
>
> I understand you did time with Illustra. I thought they had solved the
> optimizer plug-in issue...how did they do it?
>
> Best Regards, Simon Riggs
>
>
> -------- Forwarded Message --------
> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
> Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Michael Fuhr <mike(at)fuhr(dot)org>,
>
> Subject: Re: [PERFORM] Functionscan estimates
> Date: Sat, 09 Apr 2005 00:00:56 -0400
> Not too many releases ago, there were several columns in pg_proc that
> were intended to support estimation of the runtime cost and number of
> result rows of set-returning functions. I believe in fact that these
> were the remains of Joe Hellerstein's thesis on expensive-function
> evaluation, and are exactly what he was talking about here:
> http://archives.postgresql.org/pgsql-hackers/2002-06/msg00085.php
>
> But with all due respect to Joe, I think the reason that stuff got
> trimmed is that it didn't work very well. In most cases it's
> *hard* to write an estimator for a SRF. Let's see you produce
> one for dblink() for instance ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>