Message-ID: <446200F9.3070109@logix-tt.com>
Date: Wed, 10 May 2006 17:04:25 +0200
From: Markus Schaber <schabi@logix-tt.com>
Organization: Logical Tracking and Tracing International AG, Switzerland
User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
MIME-Version: 1.0
To: PFC <lists@peufeu.com>
Cc: pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal
References: <445F7FF8.6070707@comcast.net>
	<1147110142.32369.7.camel@archimedes>
	<20060508175013.GY99570@pervasive.com>
	<28288.1147111196@sss.pgh.pa.us> <op.s89zl30wcigqcu@apollo13>
	<20060509105214.P90693@vesihiisi.cksoft.de>
	<op.s8916gm6cigqcu@apollo13>
	<758d5e7f0605090943p1bbfdae2p4cb28ba128288316@mail.gmail.com>
	<op.s9amckxhcigqcu@apollo13> <4461EAAC.7030105@logix-tt.com>
	<op.s9cayhotcigqcu@apollo13>
In-Reply-To: <op.s9cayhotcigqcu@apollo13>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi, PFC,

PFC wrote:

>     You need to do some processing to know how many rows the function
> would  return.
>     Often, this processing will be repeated in the function itself.
>     Sometimes it's very simple (ie. the function will RETURN NEXT each 
> element in an array, you know the array length...)
>     Sometimes, for functions returning few rows, it might be faster to 
> compute the entire result set in the cost estimator.

I know, but we only have to estmiate the number of rows to give a hint
to the query planner, so we can use lots of simplifications.

E. G. for generate_series we return ($2-$1)/$3, and for some functions
even constant estimates will be good enough.

>     - please execute me and store my results in a temporary storage,
> count  the rows returned, and plan the outer query accordingly

That's an interesting idea.

Markus


-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org