Re: Frequent Update Project: Design Overview of HOTUpdates

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

>> Seems like "altering the row length" isn't the issue, it's just "is
>> there room on the page for the new version". Again, a generous
>> fillfactor would give you more flexibility.
>
> The copy-back operation can only work if the tuple fits in the same
> space as the root tuple. If it doesn't you end up with a tuple
> permanently in the overflow relation. That might not worry us, I guess.

I think he's suggesting that you can put the new version in the available
space rather than use the space from the existing tuple. You can keep the same
line pointer so index entries still refer to the correct tuple.

The only problem I see is that if you determine that there's space available
when you do the update that space may have disappeared by the table you come
along to do the move-back.

Perhaps you can do something clever with reserving the space at that time for
the later move-back but I fear that'll complicate vacuum and open up risks if
the system crashes in that state.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com