Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id DD7BC2E41C3 for ; Tue, 5 Feb 2008 06:06:48 -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 33831-03-3 for ; Tue, 5 Feb 2008 06:06:41 -0400 (AST) Received: from outmail136010.authsmtp.co.uk (outmail136010.authsmtp.co.uk [62.13.136.10]) by postgresql.org (Postfix) with ESMTP id 0B3662E3D54 for ; Tue, 5 Feb 2008 05:07:31 -0400 (AST) Received: from outmail128181.authsmtp.net (outmail128181.authsmtp.net [62.13.128.181]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id m1597SCs067679; Tue, 5 Feb 2008 09:07:28 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 m1597RVa037326; Tue, 5 Feb 2008 09:07:27 GMT Subject: Re: Benchmark Data requested From: Simon Riggs To: "Jignesh K. Shah" Cc: Greg Smith , pgsql-performance@postgresql.org In-Reply-To: <47A797E5.4000507@sun.com> References: <1202150236.4252.521.camel@ebony.site> <47A797E5.4000507@sun.com> Content-Type: text/plain Date: Tue, 05 Feb 2008 09:08:14 +0000 Message-Id: <1202202494.4252.631.camel@ebony.site> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-Server-Quench: c5f52ec1-d3c9-11dc-9554-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFaABba1xT HGQLW1xEUFR7WWR/ aQ0fZQBDYEtPQQZr TkxLXVBXCwUmXB0E Dxl8NEhydAJFeng+ ZEVmWD4IWRJ/dxMu Q1MAFj4PeGZhPDMC 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/24 X-Sequence-Number: 28566 On Mon, 2008-02-04 at 17:55 -0500, Jignesh K. Shah wrote: > Doing it at low scales is not attractive. > > Commercial databases are publishing at scale factor of 1000(about 1TB) > to 10000(10TB) with one in 30TB space. So ideally right now tuning > should start at 1000 scale factor. I don't understand this. Sun is currently publishing results at 100GB, 300GB etc.. Why would we ignore those and go for much higher numbers? Especially when you explain why we wouldn't be able to. There isn't any currently valid result above 10 TB. If anybody is going to run tests in response to my request, then *any* scale factor is interesting, on any hardware. If that means Scale Factor 1, 3, 10 or 30 then that's fine by me. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com