Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 1DD20476EB0; Thu, 12 Dec 2002 17:08:55 -0500 (EST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [63.150.15.178]) by postgresql.org (Postfix) with ESMTP id E91D7476F50; Thu, 12 Dec 2002 17:03:55 -0500 (EST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 5FD05D60A; Thu, 12 Dec 2002 14:03:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 4D6F15C02; Thu, 12 Dec 2002 14:03:56 -0800 (PST) Date: Thu, 12 Dec 2002 14:03:56 -0800 (PST) From: Stephan Szabo To: Jean-Luc Lachance Cc: , Subject: Re: CLUSTER command In-Reply-To: <3DF90042.E5290B7F@nsd.ca> Message-ID: <20021212135913.Q11714-100000@megazone23.bigpanda.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200212/669 X-Sequence-Number: 34584 On Thu, 12 Dec 2002, Jean-Luc Lachance wrote: > Hi all, > > I just read about the cluster command and was a little (very) > disapointed. > Clustered tables do not remain clustered after inserts. > Clustered tables are usefull when the table is very large and there are > few different keys. > > > Because the table file is already extended (2G limit) using different > files extension (.N) > how complicated (modifying the code) would it be to have the table files > split according to the cluster key? I'd vote against changing the existing CLUSTER since the existing CLUSTER while not great does handle many different key values fairly well as well and this solution wouldn't. Many different key values are still useful to cluster if you're doing searches over ranges since it lowers the number of heap file reads necessary. If done this should probably be separate from the existing cluster or at least both versions should be possible.