Simon Riggs wrote:
> On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>> HOT can only work in cases where a tuple does not modify one of the
>>> columns defined in an index on the table, and when we do not alter the
>>> row length of the tuple.
>> 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.
>
> Also, my understanding was that an overwrite operation could not vary
> the length of a tuple (at least according to code comments).
You can't If someone else has the page pinned,
>
>>> [We'll be able to do that more efficiently when
>>> we have plan invalidation]
>> Uh, what's that got to do with it?
>
> Currently the HOT code dynamically tests to see if the index columns
> have been touched. If we had plan invalidation that would be able to be
> assessed more easily at planning time, in cases where there is no BEFORE
> trigger.
>
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
