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 ?
Best,
Oliveiros
----- Original Message -----
From: "Scott Marlowe" <scott.marlowe@xxxxxxxxx>
To: "Jonathan Hoover" <jhoover@xxxxxxxxxxxxx>
Cc: <pgsql-admin@xxxxxxxxxxxxxx>
Sent: Friday, November 05, 2010 3:17 PM
Subject: Re: Get Postgres to use multiple proc cores?
On Fri, Nov 5, 2010 at 8:59 AM, Jonathan Hoover <jhoover@xxxxxxxxxxxxx>
wrote:
With my hard drive issues from an earlier email solved (thanks all) I am
now running queries against my 65M rows. I noticed in atop that postmaster
is using 100% of just one processor core. Is there any way to tell it to
use both (or at least some of the other one). System is RHEL5, PG is
version 8.1.18 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-46). Intel Core 2 Duo, 4 GB RAM.
The query in question has been running for 15 minutes, and the only thing
atop is reporting in the "red" is the processor. Although, just now the
proc has died down and the drive is apparently now "red" (the main delay
point). Here is the query (any help on improving it?)
A group by is almost always faster than a distinct.
And a single query uses a single core, sorry.
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
