Re: Project suggestion: benchmark utility for PostgreSQL

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