Re: Support Parallel Query Execution in Executor
| От | lister@sacadia.com |
|---|---|
| Тема | Re: Support Parallel Query Execution in Executor |
| Дата | |
| Msg-id | 0IXH00E121NN1B00@mailhost.konicorp.com обсуждение исходный текст |
| Ответ на | Support Parallel Query Execution in Executor ("Qingqing Zhou" <zhouqq@cs.toronto.edu>) |
| Ответы |
Re: Support Parallel Query Execution in Executor
|
| Список | pgsql-hackers |
I am working with Solaris on SPARC almost exclusively and I believe Josh said that Sun was the one who found the bursty
behaviorwith scans. Has it been confirmed that this is the case on all/most platforms?
Myron Scott
-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
Subj: Re: [HACKERS] Support Parallel Query Execution in Executor
Date: Sun Apr 9, 2006 11:48 am
Size: 1K
To: Gregory Maxwell <gmaxwell@gmail.com>
cc: pgsql-hackers@postgresql.org
"Gregory Maxwell" <gmaxwell@gmail.com> writes:
> On 4/9/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So before we go inventing complicated bits of code with lots of added
>> overhead, we should first find out exactly why the system doesn't
>> already work the way it's supposed to.
> But is that really the behavior we should expect?
Certainly. If the OS has readahead logic at all, it ought to think that
a seqscan of a large table qualifies. Your arguments seem to question
whether readahead is useful at all --- but they would apply *just as
well* to an app doing its own readahead, which is what is really
getting proposed in this thread.
Before we go replacing a standard OS-level facility with our own
version, we need to have a much clearer idea of why the OS isn't getting
the job done for us. Otherwise we're likely to write a large amount of
code and find out that it doesn't work very well either.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
В списке pgsql-hackers по дате отправления: