Re: Does larger i/o size make sense?

2013/8/23 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
>> 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.
>
>
> Indeed.
>
> Would it make sense to have something easier to configure that recompiling
> postgresql and managing a custom executable, say a block size that could be
> configured from initdb and/or postmaster.conf, or maybe per-object settings
> specified at creation time?
>
I love the idea of per-object block size setting according to expected workload;
maybe configured by DBA. In case when we have to run sequential scan on
large tables, larger block size may have less pain than interruption per 8KB
boundary to switch the block being currently focused on, even though random
access via index scan loves smaller block size.

> Note that the block size may also affect the cache behavior, for instance
> for pure random accesses, more "recently accessed" tuples can be kept in
> memory if the pages are smaller. So there are other reasons to play with the
> blocksize than I/O access times, and an option to do that more easily would
> help.
>
I see. Uniformed block-size could simplify the implementation, thus no need
to worry about a scenario that continuous buffer allocation push out pages to
be kept in memory.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>