I would like to start contributing to BenchmarkSQL with a few small patches. These are intended to make the current jTPCC more spec compliant in several aspects, which is going to be good to have for something larger, I am working on.
The small issues so far are:
some cosmetic changes to the build.xml to get stack traces in exceptions.
Have the loader conform to clause 4.3.3.1 and generate the C_LAST for the first 1,000 customers per district by using their C_ID-1 instead of a random number. That guarantees that all possible last names exist in all districts and allows to use the lookup of customer by last name in Payment and OrderStatus.
Change the non uniform number generation to conform to clause 2.1.6.1. In particular I want to add the missing C value. This will require to create a configuration table where the Loader will save the C values from the load so the benchmark run can pick an allowed random value.
The question is how do you prefer patch submissions? I did not find an official repo on Github. Would a "git show" output of a local commit work for you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings Jan. It is a pleaseure to have you as a trusted contributor to this project. I trust you're expert judgement and your impartiality. We need to continue to make sure that any changes we make to this project are not designed to favor one database over another.
--Luss
PS to others... It is true that perhaps Jan and myself are biased toward PostgreSQL or/or EnterpriseDB, but, this BenchmarkSQL project is NOT.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For others: I am a PostgreSQL contributor since 1995 and a former PostgreSQL core team member. It would be surprising if I wasn't biased towards PostgreSQL.
That said, this bias is reason enough by itself to keep a benchmark like this database vendor neutral. Even though PostgreSQL is open source, database users are our "customers". It would be a disservice to our customers to rig benchmarksql in favor of one vendor over another.
That does not mean that we cannot offer multiple options to the user. For example many other benchmarks implement entire transactions in stored procedures (like DBT2 and HammerDB, just to name two). There would be nothing wrong in offering that as an option. What would be wrong is running a comparision of database A using stored procedures against database B without using them, unless database B doesn't have the capability of stored procedures at all. And even if both are using stored procedures it becomes very difficult to make sure, they are both implemented at an equal level. However, it would be perfectly fine to test PostgreSQL with stored procedures against PostgreSQL without, to see if one implementation performs better than the other. And that is definitely a question worth answering too.
Regards, Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
my name is Jan ... yes, Denis, that Jan :)
I would like to start contributing to BenchmarkSQL with a few small patches. These are intended to make the current jTPCC more spec compliant in several aspects, which is going to be good to have for something larger, I am working on.
The small issues so far are:
The question is how do you prefer patch submissions? I did not find an official repo on Github. Would a "git show" output of a local commit work for you?
Greetings Jan. It is a pleaseure to have you as a trusted contributor to this project. I trust you're expert judgement and your impartiality. We need to continue to make sure that any changes we make to this project are not designed to favor one database over another.
--Luss
PS to others... It is true that perhaps Jan and myself are biased toward PostgreSQL or/or EnterpriseDB, but, this BenchmarkSQL project is NOT.
I could not agree more.
For others: I am a PostgreSQL contributor since 1995 and a former PostgreSQL core team member. It would be surprising if I wasn't biased towards PostgreSQL.
That said, this bias is reason enough by itself to keep a benchmark like this database vendor neutral. Even though PostgreSQL is open source, database users are our "customers". It would be a disservice to our customers to rig benchmarksql in favor of one vendor over another.
That does not mean that we cannot offer multiple options to the user. For example many other benchmarks implement entire transactions in stored procedures (like DBT2 and HammerDB, just to name two). There would be nothing wrong in offering that as an option. What would be wrong is running a comparision of database A using stored procedures against database B without using them, unless database B doesn't have the capability of stored procedures at all. And even if both are using stored procedures it becomes very difficult to make sure, they are both implemented at an equal level. However, it would be perfectly fine to test PostgreSQL with stored procedures against PostgreSQL without, to see if one implementation performs better than the other. And that is definitely a question worth answering too.
Regards, Jan