From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, List pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: WIP Join Removal |
Date: | 2008-09-02 11:05:38 |
Message-ID: | 87od36u7st.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Same answer, just slower. Removing the join makes the access to a into a
> SeqScan, whereas it was a two-table index plan when both tables present.
> The two table plan is added by the immediately preceding call add_... -
> i.e. that plan is only added during join time not during planning of
> base relations.
Perhaps it would clearer to discuss a non-outer join here:
select invoices.*
from customer join invoices using (company_id,customer_id)
where customer_id = ?
where there's a foreign key relation guaranteeing that every invoice has a
matching <company_id, customer_id>.
If there's an index on customer(customer_id) but not on invoices(customer_id)
then conceivably it would be faster to use that than scan all of the invoices.
I wonder if it would be more worthwhile to remove them and have a subsequent
phase where we look for possible joins to *add*. So even if the user writes
"select * from invoices where customer_id=?" the planner might be able to
discover that it can find those records quicker by scanning customer, finding
the matching <company_id,customer_id> and then using an index to look them up
in invoices.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-09-02 11:20:13 | Re: WIP Join Removal |
Previous Message | Heikki Linnakangas | 2008-09-02 11:03:24 | Re: WIP Join Removal |