Message-ID: <3DF90248.9BAF931C@nsd.ca>
Date: Thu, 12 Dec 2002 16:40:24 -0500
From: Jean-Luc Lachance <jllachan@nsd.ca>
MIME-Version: 1.0
To: pgsql-general@postgresql.org, pgsql-performance@postgresql.org
Subject: Re: [PERFORM] CLUSTER command
References: <5.1.0.14.1.20021212010621.0273d040@mbox.jaring.my>
	<5.1.0.14.1.20021212010621.0273d040@mbox.jaring.my>
	<5.1.0.14.1.20021213043655.027360b0@mbox.jaring.my>
	<3DF90042.E5290B7F@nsd.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oh, and something else, 

I think the syntax should be:

Cluster <table> on <attribute>


Maybe inheritance can be use here. 
The problem is creating the new "table" when a new key is detected.
I know, I can use rules, but the optimiser is not aware of the
clustering.

Enough from me for now.

What do you think?

JLL


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?
> 
> This would:
> 
> Greatly improve performance when the cluster key in included in search
> criteria.
> Allow for a much larger table before a file has to be split (.N).
> Simplify the management of symblinks (that's something else we need to
> look at).
> The index file for that field would no longer be required.
> 
> Of course, there should be only one cluster key per table.
> The length the "key" should be short and the number of unique key should
> be low as well.
> 
> SO... ?
> 
> JLL
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org