Skip site navigation (1) Skip section navigation (2)

Re: pre-algebra discussion - HOT?

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Selena Deckelmann <selenamarie(at)gmail(dot)com>
Cc: Rich Shepard <rshepard(at)appl-ecosys(dot)com>, pdxpug(at)postgresql(dot)org
Subject: Re: pre-algebra discussion - HOT?
Date: 2007-09-20 21:25:13
Message-ID: 1190323513.5943.94.camel@dogma.ljc.laika.com (view raw or flat)
Thread:
Lists: pdxpug
On Thu, 2007-09-20 at 13:57 -0700, Selena Deckelmann wrote:
> HOT (Heap Overflow Tuple) is intended to improve update behavior on
> heavily updated tables.

At some point (exactly when, I'm not sure), they changed the name to
mean "Heap Only Tuple," which more accurately represents what's
currently happening. The original design of HOT used overflow segments
of the table to isolate the heavily-updated tuple versions (if I
remember correctly), and was designed to be a table option (like
fillfactor).

The newer design is enabled for all tables, and performs the HOT update
only when it can fit the newer version in the same page as the old
tuple. In practice, this results in "overflow pages" for tuples which
are heavily updated, because they will first be updated normally ("COLD"
update) and then the fresh page will have plenty of room for subsequent
HOT updates.

However, the design is not focused on the "overflow" aspect anymore,
it's more focused on avoiding index updates by allowing tuples that
exist only in the heap and are referenced by the index only indirectly
through the ctid chain; hence "heap only tuple". In 8.2 it's impossible
to have a tuple that exists in the heap without an index entry (assuming
there is an index on the table), but with HOT you can have more tuples
in the heap than index entries.

Regards,
	Jeff Davis


In response to

pdxpug by date

Next:From: Mark WongDate: 2007-09-20 22:55:56
Subject: ptop - 'top' for postgresql
Previous:From: Jeff DavisDate: 2007-09-20 21:10:18
Subject: Re: pre-algebra discussion - HOT?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group