"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> 2. Pointer swinging. At the moment, after a row is HOT updated, the only
> way to get rid of the redirecting line pointer is to run VACUUM FULL or
> CLUSTER (or delete or cold update the row and vacuum). If we want to
> implement pointer swinging before release, we have to get started now.
> If we're happy to release without it and address the issue in later
> releases if it seems important, we need to make a conscious decision on
> that, now. I personally think we can release without it.
For the record, there was an alternative here which avoided having to do
pointer swinging. If we avoided ever returning a reference to the new line
pointer we could swap the record back to the original line pointer when it
becomes reusable again.
IIRC there were a couple reasons why this was considered a bad idea though:
a) This would require declaring that HOT updates to records don't change the
tid of the record which would be a user visible behaviour change. I'm not sure
if it would be worse or better from the point of view of ODBC, but the
non-deterministic nature of HOT updates makes it hard to imagine it being very
useful
b) Finding the root of the HOT update chain to use in the place of the "real"
tid of the record is not an especially cheap operation.
If we could find a way to arrange for the tids returned to users to *never*
change on updates that would be pretty useful from a user's point of view. But
just doing it for HOT updates and not COLD updates seems broken.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com