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
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 |