Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id E098E1337B8F for ; Fri, 5 Nov 2010 13:24:30 -0300 (ADT) 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 33316-03 for ; Fri, 5 Nov 2010 16:24:23 +0000 (UTC) Received: from news.hub.org (news.hub.org [200.46.204.72]) by mail.postgresql.org (Postfix) with ESMTP id 52CF81337B88 for ; Fri, 5 Nov 2010 13:24:23 -0300 (ADT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.14.4/8.14.4) with ESMTP id oA5GONlT072541 for ; Fri, 5 Nov 2010 13:24:23 -0300 (ADT) (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.14.4/8.14.4/Submit) id oA5G82DF063220 for pgsql-performance@postgresql.org; Fri, 5 Nov 2010 13:08:02 -0300 (ADT) (envelope-from news) From: Chris Browne X-Newsgroups: pgsql.performance Subject: Re: Running PostgreSQL as fast as possible no matter the consequences Date: Fri, 05 Nov 2010 11:13:34 -0400 Organization: cbbrowne Computing Inc Lines: 20 Message-ID: <8739rfst0h.fsf@cbbrowne.afilias-int.info> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:etMWGWlpUfacd//1N7V/BN4MUHY= To: pgsql-performance@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.79 tagged_above=-10 required=5 tests=BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201011/59 X-Sequence-Number: 41083 gentosaker@gmail.com (A B) writes: > If you just wanted PostgreSQL to go as fast as possible WITHOUT any > care for your data (you accept 100% dataloss and datacorruption if any > error should occur), what settings should you use then? Use /dev/null. It is web scale, and there are good tutorials. But seriously, there *are* cases where "blind speed" is of use. When loading data into a fresh database is a good time for this; if things fall over, it may be pretty acceptable to start "from scratch" with mkfs/initdb. I'd: - turn off fsync - turn off synchronous commit - put as much as possible onto Ramdisk/tmpfs/similar as possible -- output = reverse("moc.liamg" "@" "enworbbc") http://linuxfinances.info/info/lsf.html 43% of all statistics are worthless.