Re: HOT patch - version 14 - Mailing list pgsql-patches

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> "Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
>> Please see the version 14 of HOT patch attached.
>
> I expected to find either a large new README, or some pretty substantial
> additions to existing README files, to document how this all works.
> The comments included do not represent nearly enough documentation.

The Heikki and I posted a two-part README of sorts:

http://archives.postgresql.org/pgsql-patches/2007-07/msg00142.php
http://archives.postgresql.org/pgsql-patches/2007-07/msg00360.php

> One thing I was unable to discern from the comments is how CREATE INDEX
> can work at all.  A new index might mean that tuples that could formerly
> legally be part of the same hot-chain no longer can.  I can't find any
> code here that looks like it's addressing that.

This is one of the weirdest things in HOT and one of the hardest problems it
faced. The best solution proposed was to index the head of the HOT chain and
just ban older transactions which might be able to see the older versions fro
using the index.

That's the purpose of the indcreatexid column. It's set in
index_set_createxid() and checked in get_relation_info().

> I also don't think I believe the reasoning for not indexing
> DELETE_IN_PROGRESS hot-updated tuples: what if the index completion commits,
> but the concurrent delete rolls back? Then you've got a valid tuple that's
> not in the index.

You're talking about the concurrent index build case? Wouldn't the second pass
pick up that tuple? I have to look back at it to see for sure.

> The redefinition of the value of MaxHeapTuplesPerPage seems pretty
> ugly and unprincipled.  I think it'd be better to leave it as-is,
> and just enforce that we don't allow more than that many line pointers
> on a heap page (as indeed you have to do anyway, so it's not clear
> what the change is buying).

Note that in a heavily updated table basically every tuple will have two line
pointers, the head which just redirects to another line pointer, and the line
pointer for the actual tuple. It's hard to get rid of the actual head line
pointer without declaring that the tid might sometimes not change after an
update.

Not sure what this translates to for MaxHeapTuplesPerPage though.

The rest I know less about and will leave to Pavan and Heikki (or anyone else
who was following those details more closely).

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com