2013/8/23 Tom Lane <tgl@sss.pgh.pa.us>:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>> An idea that I'd like to investigate is, PostgreSQL allocates a set of
>>> continuous buffers to fit larger i/o size when block is referenced due to
>>> sequential scan, then invokes consolidated i/o request on the buffer.
>
>> Isn't this dealt with at least in part by effective i/o concurrency
>> and o/s readahead?
>
> I should think so. It's very difficult to predict future block-access
> requirements for anything except a seqscan, and for that, we expect the
> OS will detect the access pattern and start reading ahead on its own.
>
> Another point here is that you could get some of the hoped-for benefit
> just by increasing BLCKSZ ... but nobody's ever demonstrated any
> compelling benefit from larger BLCKSZ (except on specialized workloads,
> if memory serves).
>
> The big-picture problem with work in this area is that no matter how you
> do it, any benefit is likely to be both platform- and workload-specific.
> So the prospects for getting a patch accepted aren't all that bright.
>
Hmm. I might overlook effect of readahead on operating system level.
Indeed, sequential scan has a workload that easily launches it, so
smaller i/o size in application level will be hidden.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
