Re: Does larger i/o size make sense?

2013/8/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>