Re: Support Parallel Query Execution in Executor - Mailing list pgsql-hackers

From Gregory Maxwell
Subject Re: Support Parallel Query Execution in Executor
Date
Msg-id e692861c0604091404g7f8fbf0ayec135086da03e128@mail.gmail.com
Whole thread Raw
In response to Re: Support Parallel Query Execution in Executor  ("Luke Lonergan" <llonergan@greenplum.com>)
Responses Re: Support Parallel Query Execution in Executor  ("Luke Lonergan" <llonergan@greenplum.com>)
List pgsql-hackers
On 4/9/06, Luke Lonergan <llonergan@greenplum.com> wrote:
> Gregory,
>
> On 4/9/06 1:36 PM, "Gregory Maxwell" <gmaxwell@gmail.com> wrote:
>
> > It might also be interesting for someone with the right testing rig on
> > linux to try the adaptive
> > readahead patch to see if that improves PG's ability to keep the disk busy.
>
> "the" adaptive readahead patch?  Did I miss one?
>
> We will happily test experimental patches that improve I/O utilitization.
> We have an assortment of gear with high speed I/O, mostly Linux now.

Linux kernel patch, I'd mentioned it in a prior post.

http://www.vanheusden.com/ara/

It increases Linux's maximum readahead from 128K to 1meg .. and it
should be smart enough that you could crank it up further without too
much risk of hurting performance elsewhere.

If PG's bottlenecked on seqscan due to insufficient readahead, I'd
expect this to show an improvement...  although I am still somewhat
doubtful that it'll be enough to keep the disk saturated if PG's
behavior is highly unoptimal.


pgsql-hackers by date:

Previous
From: "Luke Lonergan"
Date:
Subject: Re: Support Parallel Query Execution in Executor
Next
From: Tom Lane
Date:
Subject: Re: Support Parallel Query Execution in Executor