Re: REPOST: Nested loops row estimates always too high

From: Ow Mun Heng <Ow(dot)Mun(dot)Heng(at)wdc(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>, Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca>, pgsql-performance(at)postgresql(dot)org
Subject: Re: REPOST: Nested loops row estimates always too high
Date: 2007-09-27 06:59:13
Message-ID: 1190876353.15634.65.camel@neuromancer.home.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 2007-09-26 at 00:02 -0400, Tom Lane wrote:
> Ow Mun Heng <Ow(dot)Mun(dot)Heng(at)wdc(dot)com> writes:
> > Where can I erad more about this new "feature"?
>
> http://developer.postgresql.org/pgdocs/postgres/sql-createfunction.html
>
> http://developer.postgresql.org/pgdocs/postgres/ always has a current
> snapshot of CVS-HEAD documentation...

I read these two items

...

execution_cost

A positive number giving the estimated execution cost for the
function, in units of cpu_operator_cost. If the function returns a set,
this is the cost per returned row. If the cost is not specified, 1 unit
is assumed for C-language and internal functions, and 100 units for
functions in all other languages. Larger values cause the planner to try
to avoid evaluating the function more often than necessary.

result_rows

A positive number giving the estimated number of rows that the
planner should expect the function to return. This is only allowed when
the function is declared to return a set. The default assumption is 1000
rows.
...
[/snip]

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Csaba Nagy 2007-09-27 11:53:24 Re: Searching for the cause of a bad plan
Previous Message Radhika S 2007-09-26 18:00:42 Difference in query plan when using = or > in where clause