From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | List pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: WIP Join Removal |
Date: | 2008-09-01 19:23:19 |
Message-ID: | 48BC4127.30706@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-09-02 08:44:24 | Re: rmgr hooks and contrib/rmgr_hook |
Previous Message | Heikki Linnakangas | 2008-09-01 18:55:32 | Re: fixing bug in combocid.c |