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 44F4C9DCBE5
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 23 Dec 2005 00:28:45 -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 31737-09
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 23 Dec 2005 00:28:42 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2])
	by postgresql.org (Postfix) with ESMTP id 8484C9DCBC3
	for <pgsql-performance@postgresql.org>;
	Fri, 23 Dec 2005 00:28:41 -0400 (AST)
Received: by floppy.pyrenet.fr (Postfix, from userid 106)
	id 8356A33A68; Fri, 23 Dec 2005 05:28:40 +0100 (MET)
From: "Qingqing Zhou" <zhouqq@cs.toronto.edu>
X-Newsgroups: pgsql.performance
Subject: Re: CPU and RAM
Date: Thu, 22 Dec 2005 23:29:42 -0500
Organization: Hub.Org Networking Services
Lines: 24
Message-ID: <dofudn$1t0a$1@news.hub.org>
References: <45b42ce40512211720t164ea389wa5bfd0cbae6c80e2@mail.gmail.com>
	<878xuc8o6h.fsf@stark.xeocode.com>
X-Complaints-To: usenet@news.hub.org
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
To: pgsql-performance@postgresql.org
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.133 required=5 tests=[AWL=0.133]
X-Spam-Score: 0.133
X-Spam-Level: 
X-Archive-Number: 200512/579
X-Sequence-Number: 16400


"Greg Stark" <gsstark@mit.edu> wrote
>
> If the whole database is in RAM I wouldn't expect clustering to have any
> effect. Either you're doing a lot of merge joins or a few other cases 
> where
> clustering might be helping you, or the cluster is helping you keep more 
> of
> the database in ram avoiding the occasional disk i/o.
>

Hi Greg,

At first I think the same - notice that Tom has submitted a patch to scan a 
whole page in one run, so if Harry tests against the cvs tip, he could see 
the real benefits. For example, a index scan may touch 5000 tuples, which 
involves 5000 pairs of lock/unlock buffer, no matter how the tuples are 
distributed. After the patch, if the tuples belong to a few pages, then a 
significant number of lock/unlock are avoided.

Regards,
Qingqing