Skip site navigation (1) Skip section navigation (2)

Re: CLUSTER command

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Jean-Luc Lachance <jllachan(at)nsd(dot)ca>
Cc: <pgsql-general(at)postgresql(dot)org>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: CLUSTER command
Date: 2002-12-12 22:03:56
Message-ID: 20021212135913.Q11714-100000@megazone23.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-interfacespgsql-performance
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.



In response to

Responses

pgsql-performance by date

Next:From: Jean-Luc LachanceDate: 2002-12-12 22:15:37
Subject: Re: CLUSTER command
Previous:From: Jean-Luc LachanceDate: 2002-12-12 21:40:24
Subject: Re: [PERFORM] CLUSTER command

pgsql-interfaces by date

Next:From: Jean-Luc LachanceDate: 2002-12-12 22:15:37
Subject: Re: CLUSTER command
Previous:From: Jean-Luc LachanceDate: 2002-12-12 21:40:24
Subject: Re: [PERFORM] CLUSTER command

pgsql-general by date

Next:From: Jean-Luc LachanceDate: 2002-12-12 22:07:46
Subject: Re: Frustration with date/times/epoch in v7.3.
Previous:From: Johnson, ShaunnDate: 2002-12-12 22:03:09
Subject: Re: problems updating table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group