Ühel kenal päeval, K, 2007-02-14 kell 10:41, kirjutas Tom Lane:
> Hannu Krosing <hannu@skype.net> writes:
> > OTOH, for same page HOT tuples, we have the command and trx ids stored
> > twice first as cmax,xmax of the old tuple and as cmin,xmin of the
> > updated tuple. One of these could probably be used for in-page HOT tuple
> > pointer.
>
> This proposal seems awfully fragile, because the existing
> tuple-chain-following logic *depends for correctness* on comparing each
> tuple's xmin to prior xmax.
What kinds of correctnes guarantees does this give for same-page tuples?
The comparing of each tuple's xmin to prior xmax should stay for
inter-page ctid links.
Mostly you can think of the same-page HOT chain as one extended tuple
when looking at it from outside of that page.
> I don't think you can just wave your hands and say we don't need that cross-check.
> Furthermore it seems to me you
> haven't fixed the problem, which is that you can't remove the chain
> member that is being pointed at by off-page links (either index entries
> or a previous generation of the same tuple).
You can't remove any tuples before they are invisible for all
transactions (i.e. dead). And being dead implies that all previous
versions are dead as well. So if I can remove a tuple, I can also remove
all its previous versions as well. Or are you trying to say that VACUUM
follows ctid links of dead tuples for some purpose ?
The problem I am trying to fix is reusing in-page space without need to
touch indexes.
> As described, you've made
> that problem worse because you're trying to say we don't know which of
> the chain entries is pointed at.
There should be a flag, say HOT_CHAIN_ENTRY for the tuple the index(es)
point at. And this should be the preferred CTID for inserting new
versions once the old one is dead.
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
