Re: Why we are going to have to go DirectIO

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: "Joshua D(dot) Drake" <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 07:14:41
Message-ID: 529ED661.8060901@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/04/2013 05:40 AM, Peter Eisentraut wrote:
> On Tue, 2013-12-03 at 14:44 -0800, Josh Berkus 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.
>
> I think the problem is, it's not even clear what the deliverable might
> be. Benchmarking tools exist, and running them on a regular schedule
> shouldn't be difficult. But that doesn't find regressions between
> kernel versions, for example, or regressions in particular queries
> (unless they happen to be included in the benchmark).

I agree on the problem of specifying an exact deliverable - however
simple using some of the extisting benchmark tool and maybe augment them
by the myriad of simple "micro" level regressions we have in the form of
sql queries in the archives would be a sensible start. It might not help
for all cases but it can help for some and we learn something that might
help us building the next iteration of it. Adding say some operatimng
systems to the mix of we have the above would be fairly easy - running a
few kvm instances that get bootstrapped automatically is something that
is a solved problem.

>
> The first step here should be to work out the minimum viable product,
> and then see what it would take to get that done.

yeah we need to start somewhere and see what we can learn.

Stefan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Muraviov 2013-12-04 07:20:51 Re: Problem with displaying "wide" tables in psql
Previous Message Shigeru Hanada 2013-12-04 06:56:29 Re: Custom Scan APIs (Re: Custom Plan node)