Re: Get Postgres to use multiple proc cores?

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: "Oliveiros d'Azevedo Cristina" <oliveiros(dot)cristina(at)marktest(dot)pt>
Cc: Jonathan Hoover <jhoover(at)yahoo-inc(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Get Postgres to use multiple proc cores?
Date: 2010-11-05 15:33:47
Message-ID: AANLkTinsXrbPD_f8G7mLxRP49nQ5ZRu=5gcULVHjr5Pd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Fri, Nov 5, 2010 at 9:29 AM, Oliveiros d'Azevedo Cristina
<oliveiros(dot)cristina(at)marktest(dot)pt> wrote:
> Scott,
>
> I'd like to take this chance to ask another (related though) question.
>
> What is faster? A JOIN or a WHERE a IN (SELECT ... )
>
> I've heard that the nested subquery has a tendency to be slower, but I'd
> like to check it with people from the list.
> Is one faster than the other? Or, all in all, they run at the same speed ?

Usually the join is faster. But there's history to consider. Back in
the olden days, it was almost always faster to use a join than a where
in. Then where in got a lot of work, and it's a lot faster. So, it
depends a bit on which version your running and size of the data set
in the in. Most of the time it's pretty close, but for larger numbers
of rows in the subselect, the join is usually faster.

Of course the only way to know for sure is to test your query and see.
Make sure to run it multiple times to overcome differences in caching.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Kevin Grittner 2010-11-05 16:08:40 Re: Get Postgres to use multiple proc cores?
Previous Message Oliveiros d'Azevedo Cristina 2010-11-05 15:29:07 Re: Get Postgres to use multiple proc cores?