Re: Does larger i/o size make sense? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Does larger i/o size make sense?
Date
Msg-id 26224.1377211295@sss.pgh.pa.us
Whole thread Raw
In response to Re: Does larger i/o size make sense?  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Does larger i/o size make sense?  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Re: Does larger i/o size make sense?  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: Does larger i/o size make sense?  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Does larger i/o size make sense?
Next
From: Sergey Konoplev
Date:
Subject: Re: System catalog vacuum issues