Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id B3B5964FCF5 for ; Tue, 2 Sep 2008 08:13:29 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 73680-05 for ; Tue, 2 Sep 2008 08:13:20 -0300 (ADT) X-Greylist: delayed 00:07:36.866936 by SQLgrey-1.7.6 Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by postgresql.org (Postfix) with ESMTP id C220964FCEA for ; Tue, 2 Sep 2008 08:13:24 -0300 (ADT) Received: by qw-out-2122.google.com with SMTP id 8so182005qwh.61 for ; Tue, 02 Sep 2008 04:13:22 -0700 (PDT) Received: by 10.215.100.7 with SMTP id c7mr6076918qam.58.1220353545768; Tue, 02 Sep 2008 04:05:45 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ( [82.16.16.210]) by mx.google.com with ESMTPS id 6sm8582835qwk.1.2008.09.02.04.05.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Sep 2008 04:05:44 -0700 (PDT) To: Simon Riggs Cc: Heikki Linnakangas , List pgsql-patches Subject: Re: WIP Join Removal In-Reply-To: <1220352898.4371.355.camel@ebony.2ndQuadrant> (Simon Riggs's message of "Tue\, 02 Sep 2008 11\:54\:58 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:INBOX" 1045) References: <1220176372.4371.118.camel@ebony.2ndQuadrant> <48BC4127.30706@enterprisedb.com> <1220348487.4371.307.camel@ebony.2ndQuadrant> <48BD1374.4030504@enterprisedb.com> <1220352112.4371.349.camel@ebony.2ndQuadrant> <48BD1852.1070904@enterprisedb.com> <1220352898.4371.355.camel@ebony.2ndQuadrant> From: Gregory Stark Organization: EnterpriseDB Date: Tue, 02 Sep 2008 12:05:38 +0100 Message-ID: <87od36u7st.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/12 X-Sequence-Number: 7027 Simon Riggs 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 . 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 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!