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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Attachments:
pgbench.c.patchtext/x-patch; charset=us-asciiDownload+2-2
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Attachments:
pgbench.c.patch-v2text/plain; charset=us-asciiDownload+2-2
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers