Re: REPOST: Nested loops row estimates always too high
От | Ow Mun Heng |
---|---|
Тема | Re: REPOST: Nested loops row estimates always too high |
Дата | |
Msg-id | 1190876353.15634.65.camel@neuromancer.home.net обсуждение исходный текст |
Ответ на | Re: REPOST: Nested loops row estimates always too high (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Wed, 2007-09-26 at 00:02 -0400, Tom Lane wrote: > Ow Mun Heng <Ow.Mun.Heng@wdc.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]
В списке pgsql-performance по дате отправления: