Re: HOT WIP Patch - version 1 - Mailing list pgsql-hackers

Just to summarize:
o  Every tuple gets a heap ctido  Only the root tuple gets an index entryo  We can easily remove dead tuples that
aren'tthe root because   by definition, nothing points to them, including backends and   indexes
 

The problem is that a dead root tuple has to stay around because while
no backends can see it, the index does.  We could move a live tuple into
root ctid slot, but if we do that, the live tuple changes its ctid while
it is visible.

Could we insert index tuples for the live tuple and then remove the root
tuple, perhaps later?  So basically we break the chain at that time. 
The problem there is that we basically have nothing better than what we
have now --- we are just delaying the index insert, and I don't see what
that buys us.

Could a _new_ tuple take over the root tuple slot?  It is new, so it
doesn't have a ctid yet to change.  I think that means the index walking
could go forward or backward, but on the same page.   To illustrate,
with ctid slot numbers:[1] root INSERT[2][3][1] root INSERT[2] UPDATE[3][1] root INSERT (dead)[2] UPDATE 1[3][1] root
UPDATE2[2] UPDATE 1[3]
 

---------------------------------------------------------------------------

Heikki Linnakangas wrote:
> Pavan Deolasee wrote:
> > - We need to find a way to handle DEAD root tuples, either convert them 
> > into
> > stubs or overwrite them with a new version. We can also perform pointer
> > swinging from the index. Again there are concerns about crash-safety and
> > concurrent index-scans working properly. We don't have a community
> > consensus on any of the suggestions in this regard. But hopefully we
> > would converge on some design soon.
> 
> This seems to be the most fundamental problem we have at the moment. If 
> we stick to the basic rule we have now that a live tuple's ctid doesn't 
> change, the only way to get rid of a dead tuple at the root of the 
> update chain is by changing the index pointer. The backward-pointers 
> Hannu suggested or the "scan the whole page to find the previous tuple" 
> would allow reuse of those dead tuples for new tuples in the chain, but 
> even those methods wouldn't completely eliminate the problem.
> 
> We could say that in some scenarios we just leave behind some dead 
> tuples/stubs that can never be reclaimed. What do you guys think, if we 
> can bring it down to just an extra line pointer, would that be 
> acceptable? We could also do that for now and implement the 
> pointer-swinging later if it turns out to be a problem in practice.
> 
> What's the verdict on relaxing the "live tuple's ctid doesn't change 
> rule"? If we did allow that within a page, what would we need to change? 
>    Inside the backend we'd have to make sure that whenever a ctid is 
> used, the page is kept pinned. How likely is it that it would brake any 
> external projects, and how difficult would it be to detect the broken 
> usage pattern? It would mean that the ctid system column could change 
> within a transaction, unless we change it so that it returns the ctid of 
> the root tuple + xmin + cmin, but it'd be a user-visible change anyhow.
> 
> -- 
>    Heikki Linnakangas
>    EnterpriseDB   http://www.enterprisedb.com
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +