Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 052981337B7E for ; Fri, 7 Jan 2011 21:59:11 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 45668-01 for ; Sat, 8 Jan 2011 01:59:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mail.postgresql.org (Postfix) with ESMTP id 48FF613364DE for ; Fri, 7 Jan 2011 21:59:03 -0400 (AST) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LwXJH-1QNuYr3AKN-018LWp; Sat, 08 Jan 2011 02:59:03 +0100 Message-ID: <4D27C4E5.5000609@2ndquadrant.com> Date: Fri, 07 Jan 2011 20:59:01 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" Subject: pgbench to the MAXINT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:fzw0SB3YIT423AQ3FJIp7hijjKSkZENOQMlZ7xpQRw3 vkjS2kKapbzqN5fHoWSFV1Pw/6Lpdqh4Rtev4SPhMWGrLOoeG1 XAqQS88k6bD3fNL0aVcXrrjfOC5q5V66GI1HpuIpmDmTrVexTR AxxgmvSBS6qbdmCDY2xmxHj0UnoCVq2Mlxb713vPi1NfWHkDvQ SGth6c0q7NMfSEKu+EdxKimk42EJgORhaIyk78BRQg= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201101/50 X-Sequence-Number: 41837 At one point I was working on a patch to pgbench to have it adopt 64-bit math internally even when running on 32 bit platforms, which are currently limited to a dataabase scale of ~4000 before the whole process crashes and burns. But since the range was still plenty high on a 64-bit system, I stopped working on that. People who are only running 32 bit servers at this point in time aren't doing anything serious anyway, right? So what is the upper limit now? The way it degrades when you cross it amuses me: $ pgbench -i -s 21475 pgbench creating tables... set primary key... NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_branches_pkey" for table "pgbench_branches" NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_tellers_pkey" for table "pgbench_tellers" NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_accounts_pkey" for table "pgbench_accounts" vacuum...done. $ pgbench -S -t 10 pgbench starting vacuum...end. setrandom: invalid maximum number -2147467296 It doesn't throw any error during the initialization step, neither via client or database logs, even though it doesn't do anything whatsoever. It just turns into the quickest pgbench init ever. That's the exact threshold, because this works: $ pgbench -i -s 21474 pgbench creating tables... 10000 tuples done. 20000 tuples done. 30000 tuples done. ... So where we're at now is that the maximum database pgbench can create is a scale of 21474. That makes approximately a 313GB database. I can tell you the size for sure when that init finishes running, which is not going to be soon. That's not quite as big as I'd like to exercise a system with 128GB of RAM, the biggest size I run into regularly now, but it's close enough for now. This limit will need to finally got pushed upward soon though, because 256GB servers are getting cheaper every day--and the current pgbench can't make a database big enough to really escape cache on one of them. -- 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