Thread: pgbench with large scale factor
I noticed that "pgbench -s scale_factor" where scale_factor is larger than 20,000 (SCALE_32BIT_THRESHOLD) creates pgbench_accounts table containing 0 row without any complain. Is there any reason for this? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
> I noticed that "pgbench -s scale_factor" where scale_factor is larger > than 20,000 (SCALE_32BIT_THRESHOLD) creates pgbench_accounts table containing > 0 row without any complain. Is there any reason for this? Oops. It appeared that this was a bug prior 9.3 pgbench. Sorry for noise. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
>> I noticed that "pgbench -s scale_factor" where scale_factor is larger >> than 20,000 (SCALE_32BIT_THRESHOLD) creates pgbench_accounts table containing >> 0 row without any complain. Is there any reason for this? > > Oops. It appeared that this was a bug prior 9.3 pgbench. Sorry for noise. BTW, I saw this with 9.3.2's pgbench: 239300000 of 3800000000 tuples (-48%) done (elapsed 226.86 s, remaining -696.10 s). -48% does not seem to be quite correct to me... Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
> BTW, I saw this with 9.3.2's pgbench: > > 239300000 of 3800000000 tuples (-48%) done (elapsed 226.86 s, remaining -696.10 s). > > -48% does not seem to be quite correct to me... Included is a proposed fix for this (also fixing weired "remaining" part). If there's no objection, I will commit it. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c index 2c96fae..28ab52f 100644 --- a/contrib/pgbench/pgbench.c +++ b/contrib/pgbench/pgbench.c @@ -1720,11 +1720,11 @@ init(bool is_no_vacuum) INSTR_TIME_SUBTRACT(diff, start); elapsed_sec = INSTR_TIME_GET_DOUBLE(diff); - remaining_sec = (scale * naccounts - j) * elapsed_sec / j; + remaining_sec = ((int64)scale * naccounts - j) * elapsed_sec / j; fprintf(stderr, INT64_FORMAT "of " INT64_FORMAT " tuples (%d%%) done (elapsed %.2f s, remaining %.2f s).\n", j, (int64) naccounts *scale, - (int) (((int64) j * 100) / (naccounts * scale)), + (int) (((int64) j * 100) / (naccounts * (int64)scale)), elapsed_sec, remaining_sec); } /* let's not call the timing for each row, but only each 100 rows */
Hello Tatsuo, >> BTW, I saw this with 9.3.2's pgbench: >> >> 239300000 of 3800000000 tuples (-48%) done (elapsed 226.86 s, remaining -696.10 s). >> >> -48% does not seem to be quite correct to me... > > Included is a proposed fix for this (also fixing weired "remaining" > part). If there's no objection, I will commit it. Looks ok, but I would consider switching to "double" instead of "int64". -- Fabien.
Fabien, >> Included is a proposed fix for this (also fixing weired "remaining" >> part). If there's no objection, I will commit it. > > Looks ok, but I would consider switching to "double" instead of > "int64". Assuming you are talking about "remaining sec" part, I agree. Here is the revised patch. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c index 2c96fae..00374d8 100644 --- a/contrib/pgbench/pgbench.c +++ b/contrib/pgbench/pgbench.c @@ -1720,11 +1720,11 @@ init(bool is_no_vacuum) INSTR_TIME_SUBTRACT(diff, start); elapsed_sec = INSTR_TIME_GET_DOUBLE(diff); - remaining_sec = (scale * naccounts - j) * elapsed_sec / j; + remaining_sec = ((double)scale * naccounts - j) * elapsed_sec / j; fprintf(stderr, INT64_FORMAT "of " INT64_FORMAT " tuples (%d%%) done (elapsed %.2f s, remaining %.2f s).\n", j, (int64) naccounts *scale, - (int) (((int64) j * 100) / (naccounts * scale)), + (int) (((int64) j * 100) / (naccounts * (int64)scale)), elapsed_sec, remaining_sec); } /* let's not call the timing for each row, but only each 100 rows */
> Fabien, > >>> Included is a proposed fix for this (also fixing weired "remaining" >>> part). If there's no objection, I will commit it. >> >> Looks ok, but I would consider switching to "double" instead of >> "int64". > > Assuming you are talking about "remaining sec" part, I agree. Here is > the revised patch. Done. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp