Tom Lane wrote:
> "Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
>> I would actually think twice before even doing this because this would
>> lead to complete change in heap page structure and stop people from
>> upgrading to 8.3 without a complete dump/restore. I don't remember 8.3
>> introduces any other significant change which already enforces that.
>
> Then you don't remember far enough --- either the HeapTupleHeader change
> or the varvarlena change would be enough to prevent that. For that
> matter, the pd_flags header field that the patch is already relying on
> is new for 8.3.
Yeah, those changes will need to be dealt with in the conversion. But
none of the changes this far have increased the on-disk size. Adding a
new field to page header means that in some corner cases it might not be
possible to convert a page from old format to the new one because the
data no longer fits.
But let's not hang ourselves on that. I'm sure there's a way to deal
with the page format conversion if we have to. The crucial design
decision for HOT is when to prune and when to defragment the page, so
that when we're doing the UPDATE, there's room in the page.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
