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?

---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to