X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 601739DCA0B for ; Sun, 15 Jan 2006 18:20:19 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 68735-05 for ; Sun, 15 Jan 2006 18:20:20 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 084349DC9A1 for ; Sun, 15 Jan 2006 18:20:15 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k0FMJud5017224; Sun, 15 Jan 2006 17:19:56 -0500 (EST) To: Michael Fuhr cc: "Dean Gibson (DB Administrator)" , pgsql-sql Subject: Re: What does "merge-joinable join conditions" mean ???? In-reply-to: <20060115215448.GA30809@winnie.fuhr.org> References: <43CAAFA6.6050001@ultimeth.com> <20060115215448.GA30809@winnie.fuhr.org> Comments: In-reply-to Michael Fuhr message dated "Sun, 15 Jan 2006 14:54:48 -0700" Date: Sun, 15 Jan 2006 17:19:56 -0500 Message-ID: <17223.1137363596@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.089 required=5 tests=[AWL=0.089] X-Spam-Score: 0.089 X-Spam-Level: X-Archive-Number: 200601/81 X-Sequence-Number: 23870 Michael Fuhr writes: > The 8.0.5 Release Notes have the following item, but without seeing > your query it's hard to know whether this fix is relevant to your > problem (the fix mentions RIGHT JOIN; your error says FULL JOIN): Good catch, but that bug was specific to left/right joins (basically, the code failed to force the join to be flipped around when needed). With a FULL JOIN you're stuck ... flipping it doesn't help. The reason it's an issue is that for a FULL JOIN, the executor has to keep track of whether rows on *both* sides of the join have been matched to any rows of the other side. If there are join conditions that are outside the mergejoin list then this requires an indefinitely large amount of state. It'd be possible to teach hash join to implement FULL JOIN (basically, you'd have to add an I've-been-joined flag to each entry in the hash table, and then re-scan the hash table at the end of the join to see which inner-side rows remain unjoined). With this you'd only need one hashable join condition to make it work, whereas the FULL JOIN mergejoin code requires *all* the join conditions to be mergejoinable. The issue hasn't come up often enough to make it seem like a high-priority problem, however. I can only recall one or two people complaining about it in all the time we've had outer-join support. regards, tom lane