Simon Riggs <[EMAIL PROTECTED]> 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! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
