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?
>
