Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 385631336971 for ; Mon, 7 Feb 2011 12:03:53 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 09161-02 for ; Mon, 7 Feb 2011 16:03:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.postgresql.org (Postfix) with ESMTP id 58B911337B54 for ; Mon, 7 Feb 2011 12:03:45 -0400 (AST) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lpzv9-1QJJLj05EV-00f6h7; Mon, 07 Feb 2011 17:03:44 +0100 Message-ID: <4D5017DE.90404@2ndquadrant.com> Date: Mon, 07 Feb 2011 11:03:42 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Euler Taveira de Oliveira CC: Pgsql Hackers Subject: Re: [PERFORM] pgbench to the MAXINT References: <4D27C4E5.5000609@2ndquadrant.com> <4D2A965A.3000603@timbira.com> <4D2AC273.3010709@2ndquadrant.com> <4D2CCCD9.802@timbira.com> <4D35DF33.6060901@2ndquadrant.com> In-Reply-To: <4D35DF33.6060901@2ndquadrant.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ZZ2LnS9FTZ7Zzy0aSOSpFeKOb9DQIQoWTAxnNM3HRXe u8kQihQYpA6gGOiu0EqDZS9IVBndc/SX8Qfh+iCfJ10kg6wz0c IxbMEdc1wZvDWXUPY6P5YSgd/lkStlNPorP6621NnZ1QAGsJLf 3+1J/Dd8oXzGFCJg07fdjKl0U0YC4apssN8jctu/dX8ZtHCyYj kQTHm3LAGW2z43BnmsJpF9RQ3H3MJizIRszBJL/mP8= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201102/449 X-Sequence-Number: 181238 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