Date: Wed, 23 Oct 2002 08:12:27 -0700 (PDT)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Tomasz Myrta <jasiek@klaster.net>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: sub-select with aggregate
In-Reply-To: <3DB6B7F7.2030609@klaster.net>
Message-ID: <20021023081036.M5349-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 23 Oct 2002, Tomasz Myrta wrote:

> Uz.ytkownik Stephan Szabo napisa?:
> > But you can't do that anyway, because you don't expose group_id
> > in the original query.  I assume user_id was a mistake then and was
> > meant to be group_id or that both were meant to be in the
> > select list.
> Yes, I meant group_id, but in orginal query I didn't have to add
> group_id to select list.

Without group_id in the select list you couldn't do a where
group_id = <something> if the select was a view.

> > In the first case changing the order means that the output
> > group_id column is X.group_id rather than users.group_id
> > (using removes one of them which is why group_id isn't
> > ambiguous.  In the second it uses on to get both group_ids
> > and exposes the one from X.
> The problem isn't ambigous columns, but speed.
> I think Postgres first performs sub-query with all records from table
> (it takes very long time). After this Postgres permforms joining table
> with sub-query. The question is: How to speed up query like this? How to
> give param group_id from first table (users) to subquery?

Did you see the other two queries I gave?  On 7.3, both of those queries
appear (according to explain output) to do the limiting of group_id
inside the subquery rather than doing the subquery with all rows.
The explanation above was why I believe it was different from your
original query.