X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 8D9B09DCB92 for ; Fri, 27 Jan 2006 21:27:32 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 36850-07 for ; Fri, 27 Jan 2006 21:27:35 -0400 (AST) Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 826DB9DCB5E for ; Fri, 27 Jan 2006 21:27:30 -0400 (AST) Received: from dbeat.com (unknown [208.234.8.166]) by svr4.postgresql.org (Postfix) with ESMTP id 1EA935AF86B for ; Sat, 28 Jan 2006 01:27:34 +0000 (GMT) Received: from videobox (cpe-24-90-163-242.nj.res.rr.com [24.90.163.242]) by dbeat.com (8.12.10/8.11.6) with SMTP id k0S1RVFU005767 for ; Fri, 27 Jan 2006 20:27:31 -0500 Message-ID: <007101c623a9$82207c10$0200a8c0@videobox> From: "Mike Biamonte" To: Subject: Huge Data sets, simple queries Date: Fri, 27 Jan 2006 20:23:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200601/457 X-Sequence-Number: 16935 Does anyone have any experience with extremely large data sets? I'm mean hundreds of millions of rows. The queries I need to run on my 200 million transactions are relatively simple: select month, count(distinct(cardnum)) count(*), sum(amount) from transactions group by month; This query took 18 hours on PG 8.1 on a Dual Xeon, RHEL3, (2.4 Kernel) with RAID-10 (15K drives) and 12 GB Ram. I was expecting it to take about 4 hours - based on some experience with a similar dataset on a different machine (RH9, PG7.3 Dual Xeon, 4GB RAM, Raid-5 10K drives) This machine is COMPLETELY devoted to running these relatively simple queries one at a time. (No multi-user support needed!) I've been tooling with the various performance settings: effective_cache at 5GB, shared_buffers at 2 GB, workmem, sortmem at 1 GB each. ( Shared buffers puzzles me a it bit - my instinct says to set it as high as possible, but everything I read says that "too high" can hurt performance.) Any ideas for performance tweaking in this kind of application would be greatly appreciated. We've got indexes on the fields being grouped, and always vacuum analzye after building them. It's difficult to just "try" various ideas because each attempt takes a full day to test. Real experience is needed here! Thanks much, Mike