Re: [PERFORM] pgbench to the MAXINT
От | Greg Smith |
---|---|
Тема | Re: [PERFORM] pgbench to the MAXINT |
Дата | |
Msg-id | 4D5017DE.90404@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] pgbench to the MAXINT (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: [PERFORM] pgbench to the MAXINT
|
Список | pgsql-hackers |
The update on the work to push towards a bigger pgbench is that I now have the patch running and generating databases larger than any previously possible scale: $ time pgbench -i -s 25000 pgbench ... 2500000000 tuples done. ... real 258m46.350s user 14m41.970s sys 0m21.310s $ psql -d pgbench -c "select pg_size_pretty(pg_relation_size('pgbench_accounts'));"pg_size_pretty ----------------313 GB $ psql -d pgbench -c "select pg_size_pretty(pg_relation_size('pgbench_accounts_pkey'));"pg_size_pretty ----------------52 GB $ time psql -d pgbench -c "select count(*) from pgbench_accounts" count ------------2500000000 real 18m48.363s user 0m0.010s sys 0m0.000s The only thing wrong with the patch sent already needed to reach this point was this line: for (k = 0; k < naccounts * scale; k++) Which needed a (int64) cast for the multiplied value in the middle there. Unfortunately the actual test itself doesn't run yet. Every line I see when running the SELECT-only test says: client 0 sending SELECT abalance FROM pgbench_accounts WHERE aid = 1; So something about the updated random generation code isn't quite right yet. Now that I have this monster built, I'm going to leave it on the server until I can sort that out, which hopefully will finish up in the next day or so. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
В списке pgsql-hackers по дате отправления: