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 4501C9DCC34 for ; Mon, 28 Nov 2005 17:45:52 -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 54723-02 for ; Mon, 28 Nov 2005 17:45:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from linda-2.paradise.net.nz (bm-2a.paradise.net.nz [203.96.152.181]) by postgresql.org (Postfix) with ESMTP id 7856E9DCC2A for ; Mon, 28 Nov 2005 17:45:49 -0400 (AST) Received: from smtp-1.paradise.net.nz (tclsnelb1-src-1.paradise.net.nz [203.96.152.172]) by linda-2.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IQO00G8VPSBIV@linda-2.paradise.net.nz> for pgsql-performance@postgresql.org; Tue, 29 Nov 2005 10:45:47 +1300 (NZDT) Received: from [192.168.1.11] (218-101-29-74.dsl.clear.net.nz [218.101.29.74]) by smtp-1.paradise.net.nz (Postfix) with ESMTP id 49B63146C748; Tue, 29 Nov 2005 10:45:47 +1300 (NZDT) Date: Tue, 29 Nov 2005 10:45:46 +1300 From: Mark Kirkwood Subject: Re: Hardware/OS recommendations for large databases ( In-reply-to: <6EE64EF3AB31D5448D0007DD34EEB3417DD97C@Herge.rcsinc.local> To: Merlin Moncure Cc: pgsql-performance@postgresql.org Message-id: <438B7A8A.4020505@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051106) References: <6EE64EF3AB31D5448D0007DD34EEB3417DD97C@Herge.rcsinc.local> 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: 200511/539 X-Sequence-Number: 15796 Merlin Moncure wrote: >>It certainly makes quite a difference as I measure it: >> >>doing select(1) from a 181000 page table (completely uncached) on my > > PIII: > >>8.0 : 32 s >>8.1 : 25 s >> >>Note that the 'fastcount()' function takes 21 s in both cases - so all >>the improvement seems to be from the count overhead reduction. > > > Are you running windows? There is a big performance improvement in > count(*) on pg 8.0->8.1 on win32 that is not relevant to this debate... > No - FreeBSD 6.0 on a dual PIII 1 Ghz. The slow cpu means that the 8.1 improvements are very noticeable! A point of interest - applying Niels palloc - avoiding changes to NodeAgg.c and int8.c in 8.0 changes those results to: 8.0 + palloc avoiding patch : 27 s (I am guessing the remaining 2 s could be shaved off if I backported 8.1's virtual tuples - however that looked like a lot of work) Cheers Mark