Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 12 Nov 2008 11:45:06 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Derby optimizer for Table Function
In-reply-to: <20456636.post@talk.nabble.com>
Sender: Knut.Hatlen@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <wjo8fxlx2pfx.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <20456636.post@talk.nabble.com>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (usg-unix-v)

Reda134 <reda134@gmail.com> writes:

> Hi all, 
> The Derby devoloppers mentions in the documentation of table functions, that
> the optimizer takes 2 Assumtions : 
>
> 1 - It Assumes by default that table functions are repeatable and thus place
> them in the inner slot of a join.
>
> 2 -  It Assumes by default that table functions are expensice and thus place
> them in the outer slot of a join.
>
> Is this not paradoxal ?? Or i get it wrong ??

I assume you're talking about this section of the developer's guide:
http://db.apache.org/derby/docs/10.4/devguide/cdevspecialtfoptimizer.html

The clue here is that it doesn't say "thus place them in the
[outer/inner] slot", but rather that it is _likely_ that the optimizer
will place the table function in an outer slot and that the optimizer
_can_ place it in an inner slot. If you for example join two table
functions, only one of them can be in the outer slot. The other one will
go in the inner slot. If none of them can go in the inner slot because
they are not repeatable, one of them will be stored in a temporary table
which can go in the inner slot.

-- 
Knut Anders