Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 82303476A0B for ; Thu, 24 Oct 2002 12:39:10 -0400 (EDT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178]) by postgresql.org (Postfix) with ESMTP id BB9904769FE for ; Thu, 24 Oct 2002 12:39:09 -0400 (EDT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id D5EBED5F7; Thu, 24 Oct 2002 09:39:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id BF5EE5C02; Thu, 24 Oct 2002 09:39:14 -0700 (PDT) Date: Thu, 24 Oct 2002 09:39:14 -0700 (PDT) From: Stephan Szabo To: Tomasz Myrta Cc: Subject: Re: sub-select with aggregate In-Reply-To: <20021024175129.M3214@klaster.net> Message-ID: <20021024093022.A21018-100000@megazone23.bigpanda.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/342 X-Sequence-Number: 10059 On Thu, 24 Oct 2002, Tomasz Myrta wrote: > > The system doesn't realize that it can limit the subquery when the only > > things it has is the join clause and the limiting clause on the other > > table. Like Tom's message about the other view, it won't imply that > > X.foo=12345 from foo=12345 when the exposed foo is B.foo. > > Is this what we should expect, or rather a bug? > The system knows how to join tables, but fails with joining views or > subselects :-( It knows how to join them, it doesn't know that it can change the clauses given to it in order to make it more efficient. Basically, as I understand it, select * from a,b where a.a=b.a and a.a=3; isn't going to realize that b.a=3 and act as if you typed that. It may consider an index scan in a nested loop for a.a=b.a, but that's not quite the same.