Hmmm. My brain is being jostled and I'm confusing illustra-postgres,
informix-postgres and postgresql. Some things had functions and
some things had constants and I do not remember which products had
what combination. But probably how they are in postgresql, post
hellerstein, is how I am rememberi
On Thu, Apr 14, 2005 at 10:39:03AM -0700, elein wrote:
> 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 expen
they had solved the
> optimizer plug-in issue...how did they do it?
>
> Best Regards, Simon Riggs
>
>
> Forwarded Message
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Alvaro Herrera <[EMAIL PROTECTED]>
> Cc: Josh Berkus , Michael Fuhr <[EMA
People:
(HACKERS: Please read this entire thread at
http://archives.postgresql.org/pgsql-performance/2005-04/msg00179.php
Sorry for crossing this over.)
> > The larger point is that writing an estimator for an SRF is frequently a
> > task about as difficult as writing the SRF itself
>
> True, a
Tom Lane wrote:
The larger point is that writing an estimator for an SRF is frequently a
task about as difficult as writing the SRF itself
True, although I think this doesn't necessarily kill the idea. If
writing an estimator for a given SRF is too difficult, the user is no
worse off than they ar
Tom Lane wrote:
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
evalua
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 09, 2005 at 12:00:56AM -0400, Tom Lane wrote:
>> 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 pro
On Sat, Apr 09, 2005 at 12:00:56AM -0400, Tom Lane wrote:
> 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
My solution would be a lot simpler, since we could simply populate
pg_proc.proestrows with "1000" by default if not changed by the DBA. In
an
even better world, we could tie it to a table, saying that, for example,
proestrows = my_table*0.02.
What if the estimated row is a function of a parame
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 ...
Good one...
Well in some cases it'll be impossible, but suppose I have
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 ex
On Fri, Apr 08, 2005 at 04:04:27PM -0700, Josh Berkus wrote:
> My solution would be a lot simpler, since we could simply populate
> pg_proc.proestrows with "1000" by default if not changed by the DBA. In an
> even better world, we could tie it to a table, saying that, for example,
> proestrows
Alvaro, Michael,
> > About a month ago I mentioned that I'd find that useful. In a
> > followup, Christopher Kings-Lynne brought up the idea of a GUC
> > variable that could give hints about the expected row count.
>
> That seems pretty limited ... what happens if the query contains more
> that o
On Fri, Apr 08, 2005 at 04:38:20PM -0600, Michael Fuhr wrote:
> On Fri, Apr 08, 2005 at 03:15:50PM -0700, Josh Berkus wrote:
> >
> > I'm wondering if it might be useful to be able to add estimated selectivity
> > to
> > a function definition for purposes of query estimation. Currently function
On Fri, Apr 08, 2005 at 03:15:50PM -0700, Josh Berkus wrote:
>
> I'm wondering if it might be useful to be able to add estimated selectivity
> to
> a function definition for purposes of query estimation. Currently function
> scans automatically return a flat default 1000 estimated rows. It s
Folks,
I'm wondering if it might be useful to be able to add estimated selectivity to
a function definition for purposes of query estimation. Currently function
scans automatically return a flat default 1000 estimated rows. It seems
like the DBA ought to be able to ALTER FUNCTION and give it
16 matches
Mail list logo
