Re: Support Parallel Query Execution in Executor

From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
To: lister(at)sacadia(dot)com, pgsql-hackers-owner+M82018(at)postgresql(dot)org, "Gregory Maxwell" <gmaxwell(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support Parallel Query Execution in Executor
Date: 2006-04-09 20:26:00
Message-ID: C05EBBE8.21311%llonergan@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Myron,

On 4/9/06 1:18 PM, "lister(at)sacadia(dot)com" <lister(at)sacadia(dot)com> wrote:

> I am working with Solaris on SPARC almost exclusively and I believe Josh said
> that Sun was the one who found the bursty behavior with scans. Has it been
> confirmed that this is the case on all/most platforms?

It was our folks at Greenplum that found this behavior. It is particularly
bad on Solaris because of the poor OS readahead on UFS. You can modify UFS
readahead behavior using OS tuning parameters as mentioned previously in the
thread and contained in Jignesh Shaw's blog at Sun (we worked with Jignesh
and Sun for about a year to get this information).

Interestingly, the use of POSIX fadvise() to indicate the nature of the I/O
as sequential makes a big positive difference in many cases, but it hurts a
lot in some other workloads where there is seek I/O and the sequential
pattern was set.

I think the best solution will use a more direct overlap approach in the
executor.

- Luke

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Maxwell 2006-04-09 20:36:54 Re: Support Parallel Query Execution in Executor
Previous Message lister 2006-04-09 20:18:00 Re: Support Parallel Query Execution in Executor