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

Re: Equivalent praxis to CLUSTERED INDEX?

From: Mischa Sandberg <ischamay(dot)andbergsay(at)activestateway(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Equivalent praxis to CLUSTERED INDEX?
Date: 2004-08-27 18:26:39
Message-ID: z1LXc.66099$X12.19104@edtnps84 (view raw or flat)
Thread:
Lists: pgsql-performance
I think you've probably fingered the kicker of why PG doesn't have this 
kind of clustering already. Hence perhaps the need for other approaches
to the issue (the disk-IO efficiency of reading groups of rows related 
by a common key) that other DB's (with in-place update) address with
synchronous clustering ('heap rebalancing' ?).

Bruce Momjian wrote:
> Adi Alurkar wrote:
> 
>>IIRC it it to reduce the "overflow" of data or what oracle calls  
>>chained rows. i.e if a table has variable length columns and 10 rows  
>>get inserted into a datapage, if this datapage is full and one of the  
>>variable length field gets updated the row will now "overflow" into  
>>another datapage, but if the datapage is created with an appropriate  
>>amount of free space the updated row will be stored in one single  
>>datapage.
> 
> 
> Agreed.  What I am wondering is with our system where every update gets
> a new row, how would this help us?  I know we try to keep an update on
> the same row as the original, but is there any significant performance
> benefit to doing that which would offset the compaction advantage?
> 

In response to

pgsql-performance by date

Next:From: Artimenko IgorDate: 2004-08-27 19:29:11
Subject: Why those queries do not utilize indexes?
Previous:From: Tom LaneDate: 2004-08-27 18:19:29
Subject: Re: Equivalent praxis to CLUSTERED INDEX?

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