Message-ID: <48BC4127.30706@enterprisedb.com>
Date: Mon, 01 Sep 2008 22:23:19 +0300
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: Simon Riggs <simon@2ndQuadrant.com>
CC: List pgsql-patches <pgsql-patches@postgresql.org>
Subject: Re: WIP Join Removal
References: <1220176372.4371.118.camel@ebony.2ndQuadrant>
In-Reply-To: <1220176372.4371.118.camel@ebony.2ndQuadrant>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

Simon Riggs wrote:
> Patch works, but there's a bit I haven't finished yet - checking unique
> indexes.

Did plan invalidation make it safe to rely on the presence of a unique 
index for planning decisions?

Couldn't we also do join removal for inner joins, when there's a foreign 
key reference that enforces that there's one and only one matching tuple 
in the removed table:

SELECT child.data FROM child, parent WHERE child.fkey = parent.pkey

?


> + 	/*
> + 	 * We can now remove join by pulling up child plan from the keeprel.
> + 	 * This needs to be done considering costs, since its possible for
> + 	 * a nested inner indexscan plan to be cheaper. So it isn't
> + 	 * always desirable to remove the join.

Can you elaborate that a bit? I can't imagine a case where we wouldn't 
want to remove a join, when we know we can.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com