Greg Stark wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
>
>> I think it would be useful to think about exactly what type of
>> query/activity we are looking to improve the performance on. That way we
>> can understand the benefit of this proposal and take some baseline
>> measurements to analyse what is happening for those cases.
>
> I find the focus on sequential scans, index scans, etc. quite odd when you're
> discussing parallel query processing. The whole goal of parallel query
> processing is to bring more *cpu* to bear on the problem. That's going to be
> most relevant when you're cpu bound, not i/o bound.
>
> The queries I would expect to be helped most by parallel query processing are
> queries that involve sorting. For example, a big merge join with two sorts on
> either side could perform the two sorts simultaneously. If they provide the
> results of the final pass to a third thread it can execute the merge join and
> the rest of the query plan while the sorts are still executing on two other
> processors.
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.
You are correct about parallel query processing helping mutliple sort
queries but those sorts may or may not hit and index.
Sincerely,
Joshua D. Drake
>
>
--
=== The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency:
+1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/