Re: Functionscan estimates

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Functionscan estimates
Date: 2005-04-08 23:57:31
Message-ID: 20050408235731.GA6279@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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 = my_table*0.02.

The problem with that approach is that it can't differ depending on the
arguments to the function, so it too seems limited to me.

Ideally an estimator would be able to peek at other table statistics and
do some computation with them, just like other nodes are able to.

Another idea would be have an estimator function (pg_proc.proestimator)
for each regular function. The estimator would be a very cheap function
to be called with the same arguments, and it would return the estimated
number of tuples the other function would return. The default estimator
could be "return 1000".

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"A wizard is never late, Frodo Baggins, nor is he early.
He arrives precisely when he means to." (Gandalf, en LoTR FoTR)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-04-09 00:50:09 Optimizing maximum/minimum queries (yet again)
Previous Message Sergey E. Koposov 2005-04-08 23:43:46 Tab-completion feature ?

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-04-09 04:00:56 Re: Functionscan estimates
Previous Message Josh Berkus 2005-04-08 23:04:27 Re: Functionscan estimates