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

From Tom Lane
Subject Re: Support Parallel Query Execution in Executor
Date
Msg-id 9279.1144600443@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support Parallel Query Execution in Executor  ("Gregory Maxwell" <gmaxwell@gmail.com>)
Responses Re: Support Parallel Query Execution in Executor  ("Gregory Maxwell" <gmaxwell@gmail.com>)
List pgsql-hackers
"Gregory Maxwell" <gmaxwell@gmail.com> writes:
> For example, one case made in this thread involved bursty performance
> with seqscans presumably because the I/O was stalling while processing
> was being performed.

Actually, the question that that raised in my mind is "why isn't the
kernel doing read-ahead properly?"  When we're doing nonsequential
access like an indexscan, it's unsurprising that the kernel can't guess
which block we need next, but in a plain seqscan you'd certainly expect
the read-ahead algorithm to kick in and ensure that the next block is
fetched before we need it.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Support Parallel Query Execution in Executor
Next
From: "Jonah H. Harris"
Date:
Subject: Re: Support Parallel Query Execution in Executor