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. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
