Re: Does larger i/o size make sense?

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Does larger i/o size make sense?
Date: 2013-08-23 06:36:29
Message-ID: alpine.DEB.2.02.1308230829390.3533@localhost6.localdomain6
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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?

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.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-08-23 06:38:32 Re: PL/pgSQL, RAISE and error context
Previous Message Kohei KaiGai 2013-08-23 05:36:09 Re: Does larger i/o size make sense?