Re: [PERFORM] CLUSTER command

Jean-Luc Lachance <jllachan@nsd.ca>

From: Jean-Luc Lachance <jllachan@nsd.ca>
To: pgsql-general@postgresql.org, pgsql-performance@postgresql.org
Date: 2002-12-12T21:40:24Z
Lists: pgsql-performance, pgsql-general
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