Re: Support Parallel Query Execution in Executor

From: Greg Stark <gsstark(at)mit(dot)edu>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support Parallel Query Execution in Executor
Date: 2006-04-11 19:00:41
Message-ID: 87vetghr8m.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:

> Well I am go out on a limb here and gather to guess that sequential scans and
> index scans are still very relevant because the CPU could be bound by the scan
> (either one) based on the type of query being performed.
>
> This doesn't really have anything to do with being IO bound as to the type of
> accesses to the data we have to deal with in regards to query processing.

It has everything to do with being i/o bound. The only way having two
processors perform part of an index or sequential scan would help is if your
disk subsystem is capable of providing data faster than a single processor is
capable of requesting it.

That's only going to be true for very high end systems with multiple raid
controllers and dozens of spindles.

On the other hand even moderately sized dual-core systems could probably
benefit from being able to perform multiple cpu-intensive operations
simultaneously.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-04-11 19:27:33 Re: semaphore usage "port based"?
Previous Message Jonah H. Harris 2006-04-11 18:39:19 Re: adding fields to pg_database

Browse pgsql-patches by date

  From Date Subject
Next Message Guillaume Smet 2006-04-11 19:57:48 Re: Patch proposal for log_duration
Previous Message Joshua D. Drake 2006-04-11 18:10:00 Re: Support Parallel Query Execution in Executor