Re: Project suggestion: benchmark utility for PostgreSQL - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Project suggestion: benchmark utility for PostgreSQL
Date
Msg-id 45FD2BFD.1050707@agliodbs.com
Whole thread Raw
In response to Project suggestion: benchmark utility for PostgreSQL  ("Mickael DELOISON" <mdeloison@gmail.com>)
List pgsql-hackers
Mickael,

> I am a student and I would like to have your opinion on a project I
> plan to submit for GSoC. At school, when I work with relational
> databases I have problems to test tables' structure and queries
> because I need to insert test data manually, which is very unpleasant.
> Therefore, I suggest creating a benchmark utility for PostgreSQL.

I think your project sounds really cool, but also not doable in 3 months 
from scratch.  You need to build on the work of others.  Simply 
designing a viable benchmark schema and data set would be a 
more-than-3-month process; developing them *and* the tools to use them 
would likely take you more than a year.  I know whereof I speak.

Therefore, I think you should attach your proposal to one of the 
following projects:

PGBuildfarm: orient your tools more towards being "performance unit 
tests" than part of a benchmark.  Your tool could then become an 
additional component of the Buildfarm, and your mentor would be Andrew 
Dunstan.  Note that this would make any GUI components the last thing 
you do.

TPC-E/DBT5: you could work with Rilson on modularizing DBT5 so that 
users could run a smaller version and do "unit tests" of parts of the 
TPCE schema/queryset.  In that case, your mentor would be Mark Wong.

OpenJPA: the JPA project is working on creating OSDB+Java performance 
unit tests as well (database-agnostic).  I know they could use help; if 
you did this, I'd recuit a JPA person to be your mentor.

EAStress: You could use Spec's recently liberalized rules to build your 
tools on top of the EAstress workload.  This would have a couple 
disadvantages, though: EAstress doesn't use database features much, and 
the workload isn't open source, just free.  In that case, your mentor 
would be me.

> For a programming language, as it would be for GSoC, it has to be
> realized in three month and I believe the utility has to be
> cross-platform (anyway I want it to be). So I think Java would be
> good. I am very used to Java and Swing programming. What do you think
> about that choice? If you feel Java is a bad choice, there is
> C++/Boost/wxWidget/ (like pgAdmin). But with wxWidget, I am not sure
> if a GUI works under Windows and Linux it will work under MacOS
> without hacks.

I don't see any issue with using Java.   As SoC administrator, my main 
concern is that you finish a usable tool, so I'd go with whatever you 
can code the best in.

Anyway, it sounds like a really cool project, and I look forward to your 
application.

--Josh Berkus


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Bug in UTF8-Validation Code?
Next
From: Josh Berkus
Date:
Subject: Re: Buildfarm feature request: some way to track/classify failures