Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id A718D2E36CC for ; Tue, 5 Feb 2008 15:48:12 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 02537-01-4 for ; Tue, 5 Feb 2008 15:48:10 -0400 (AST) Received: from outmail128095.authsmtp.net (outmail128095.authsmtp.net [62.13.128.95]) by postgresql.org (Postfix) with ESMTP id B09D02E3490 for ; Tue, 5 Feb 2008 15:48:08 -0400 (AST) Received: from outmail128179.authsmtp.co.uk (outmail128179.authsmtp.co.uk [62.13.128.179]) by punt4.authsmtp.com (8.14.1/8.14.1/Kp) with ESMTP id m15Jkq7S078992; Tue, 5 Feb 2008 19:46:52 GMT Received: from [192.168.0.3] (85-211-31-42.dyn.gotadsl.co.uk [85.211.31.42]) (authenticated bits=0) by mail.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id m15JlcY1099306; Tue, 5 Feb 2008 19:47:39 GMT Subject: Re: Benchmark Data requested From: Simon Riggs To: "Jignesh K. Shah" Cc: Dimitri Fontaine , pgsql-performance@postgresql.org, Greg Smith In-Reply-To: <47A8AF31.8070304@sun.com> References: <1202150236.4252.521.camel@ebony.site> <200802051506.51581.dfontaine@hi-media.com> <1202221496.4252.680.camel@ebony.site> <200802051815.25800.dfontaine@hi-media.com> <1202232753.4252.789.camel@ebony.site> <47A8AF31.8070304@sun.com> Content-Type: text/plain Date: Tue, 05 Feb 2008 19:48:26 +0000 Message-Id: <1202240906.4252.832.camel@ebony.site> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-Server-Quench: 350c246d-d423-11dc-9554-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksachtFaABba1xT HGQLW1xEUVR7XWR/ aAMfZQBDYEtPQQZr TkxLXVBXCwUmXB0E fEJNOxhyfgxFeHg+ Z0RmVj5YWUQpd0J7 FlMAEW8FeGZhPDMC WUVdcx5UcAJLdhoR aVd4ByJDAzANdhEA MjUdGAoUCH11JSJe QgQEN1FabU8XF3Ym SgkfEC4zEEFt X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:787/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200802/50 X-Sequence-Number: 28592 On Tue, 2008-02-05 at 13:47 -0500, Jignesh K. Shah wrote: > That sounds cool to me too.. > > How much work is to make pg_bulkload to work on 8.3? An Integrated > version is certainly more beneficial. > Specially I think it will also help for other setups like TPC-E too > where this is a problem. If you don't write WAL then you can lose all your writes in a crash. That issue is surmountable on a table with no indexes, or even conceivably with one monotonically ascending index. With other indexes if we crash then we have a likely corrupt index. For most production systems I'm aware of, losing an index on a huge table is not anything you'd want to trade for performance. Assuming you've ever been knee-deep in it on a real server. Maybe we can have a "load mode" for a table where we skip writing any WAL, but if we crash we just truncate the whole table to nothing? Issue a WARNING if we enable this mode while any data in table. I'm nervous of it, but maybe people really want it? I don't really want to invent ext2 all over again, so we have to run an fsck on a table of we crash while loading. My concern is that many people would choose that then blame us for delivering unreliable software. e.g. direct path loader on Oracle used to corrupt a PK index if you loaded duplicate rows with it (whether it still does I couldn't care). That kind of behaviour is simply incompatible with production usage, even if it does good benchmark. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com