From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | magnus(at)hagander(dot)net, josh(at)agliodbs(dot)com, stefan(at)kaltenbrunner(dot)cc, jd(at)commandprompt(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why we are going to have to go DirectIO |
Date: | 2013-12-04 02:28:29 |
Message-ID: | 20131204.112829.2284665416860121658.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Tue, Dec 3, 2013 at 11:44 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>> Would certainly be nice. Realistically, getting good automated
>>> performace tests will require paying someone like Greg S., Mark or me
>>> for 6 solid months to develop them, since worthwhile open source
>>> performance test platforms currently don't exist. That money has never
>>> been available; maybe I should do a kickstarter.
>
>> So in order to get *testing* we need to pay somebody. But to build a great
>> database server, we can rely on volunteer efforts or sponsorship from
>> companies who are interested in moving the project forward?
>
> And even more to the point, volunteers to reinvent the kernel I/O stack
> can be found on every street corner? And those volunteers won't need any
> test scaffolding to be sure that *their* version never has performance
> regressions? (Well, no, they won't, because no such thing will ever be
> built. But we do need better test scaffolding for real problems.)
Can we avoid the Linux kernel problem by simply increasing our shared
buffer size, say up to 80% of memory?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-12-04 03:57:18 | Re: Parallel Select query performance and shared buffers |
Previous Message | KONDO Mitsumasa | 2013-12-04 02:26:36 | Re: Time-Delayed Standbys |