Re: Project suggestion: benchmark utility for PostgreSQL
От | Josh Berkus |
---|---|
Тема | Re: Project suggestion: benchmark utility for PostgreSQL |
Дата | |
Msg-id | 45FD2BFD.1050707@agliodbs.com обсуждение исходный текст |
Ответ на | Project suggestion: benchmark utility for PostgreSQL ("Mickael DELOISON" <mdeloison@gmail.com>) |
Список | 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 по дате отправления: