Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id D0A69475D3B for ; Thu, 24 Oct 2002 11:19:37 -0400 (EDT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178]) by postgresql.org (Postfix) with ESMTP id 70BCC475AD4 for ; Thu, 24 Oct 2002 11:19:33 -0400 (EDT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 9C1B6D60E; Thu, 24 Oct 2002 08:19:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 8DCAE5C02; Thu, 24 Oct 2002 08:19:32 -0700 (PDT) Date: Thu, 24 Oct 2002 08:19:32 -0700 (PDT) From: Stephan Szabo To: Tomasz Myrta Cc: Subject: Re: sub-select with aggregate In-Reply-To: <3DB7BF5A.1090606@klaster.net> Message-ID: <20021024081033.U20230-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/338 X-Sequence-Number: 10055 On Thu, 24 Oct 2002, Tomasz Myrta wrote: > Now I know the solution - to speed up this query I have to manually > expose field from sub-query. It works fine, but I still don't know why I > can't do this opposite way. 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.