Re: slow sub-query problem

From: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: slow sub-query problem
Date: 2014-11-19 17:58:44
Message-ID: CAKFQuwa5pRMkBygyufwwV5Jutwh26CJWgo4e05uuadzn-EyAEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Wed, Nov 19, 2014 at 10:48 AM, daku.sandor [via PostgreSQL] <
ml-node+s1045698n5827584h28(at)n5(dot)nabble(dot)com> wrote:

> Slightly off:
>
> I prefer "exists" to "join" if it's possible while on the list I almost
> never see any answer that uses "exists". Is my exists fixation is some kind
> of bad practice?
>

​I tend not to use exists even where it is warranted...mostly because it
just sounds wrong to me for some reason. Correlated subqueries are tougher
for me to reason and understand quickly so if a join or IN version of a
query will work I tend to go that way first.

The optimizer does a decent job of making exists and joins functionally
equivalent. Exists and IN are not in the presence of NULL so I am often
concerned about using IN instead of Exists but still end up doing it and
only changing if the query performs badly.

The ON clause is more obvious than a equality condition in a where clause
in a subquery. I tend to use "JOIN (subquery) alias ON" instead of exists
too - partially to separate out the subsetting logic (WHERE) from the join
logic (ON)

David J.

--
View this message in context: http://postgresql.nabble.com/slow-sub-query-problem-tp5827273p5827589.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tim Dudgeon 2014-11-20 14:12:00 Re: slow sub-query problem
Previous Message daku.sandor 2014-11-19 09:27:08 Re: slow sub-query problem