2013/8/23 Tom Lane <t...@sss.pgh.pa.us>: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
