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