From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "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 18:48:54 |
Message-ID: | 12686.1144608534@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Gregory Maxwell" <gmaxwell(at)gmail(dot)com> writes:
> On 4/9/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2006-04-09 18:57:16 | Re: Support Parallel Query Execution in Executor |
Previous Message | Tom Lane | 2006-04-09 18:39:41 | Re: Support Parallel Query Execution in Executor |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2006-04-09 18:57:16 | Re: Support Parallel Query Execution in Executor |
Previous Message | Tom Lane | 2006-04-09 18:39:41 | Re: Support Parallel Query Execution in Executor |