Re: HOT for PostgreSQL 8.3 - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: HOT for PostgreSQL 8.3
Date
Msg-id 1171181901.3618.17.camel@localhost.localdomain
Whole thread Raw
In response to HOT for PostgreSQL 8.3  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: HOT for PostgreSQL 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Ühel kenal päeval, K, 2007-02-07 kell 17:38, kirjutas Simon Riggs:

> When we try to UPDATE a tuple and the new tuple version doesn't fit on
> the block, we get the BufferCleanupLock if possible and then perform a
> single-block VACUUM. Any tuple that is both HEAP_DEAD &
> HEAP_ONLY_TUPLE
> can be removed completely. This is possible by changing the t_ctid
> field
> so that it points at the first visible-to-someone tuple in the chain,
> so
> it points "over" the previous HOT tuples. The root tuple is also dead
> -
> it cannot be removed completely, so it is replaced it with "just a
> TupleHeader", which is referred to as a TupleStub. (Credit to Itagaki
> for this concept).

What if we would just reuse the root tuple directly instead of turning
it into a stub ?

This would create a cycle of ctid pointers, which changes the lookup
process from 'follow ctid chaint until the end' to 'follow the tid chain
until you reach the start'.

It also allows one to chill tuples for which all other tuples except the
root are dead by just flipping the HOT flag bit (or juts making the ctid
chain ptr to point to self.)

> The single-block VACUUM would alter *all* tuple chains on the block,
> not just the one for the current tuple being UPDATEd.
> 
> This technique means that a tuple never changes its CTID, so
> everything that currently uses CTID can continue normally. SeqScan
> would also work identically to the way it works today.
> 
> It also means that we can't easily remove the root tuple, even if it
> is now just a TupleStub (unless the whole chain is also removable
> because of DELETE). Removing the root tuple will require a VACUUM
> *FULL*. Even so, this option is still space-neutral in the worst-case,
> in comparison with inserting index tuples. 

if you can afford changing xmin and xmax, you can actually do it in 2
steps - first do an "update" that moves the tuple to hot chain root
position, and then, after the original is dead for all backends, just
mark it as not hot.

-- 
----------------
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





pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: XML export
Next
From: Tatsuo Ishii
Date:
Subject: tsearch2: enable non ascii stop words with C locale