> On 6/24/06, Mark Woodward <[EMAIL PROTECTED]> wrote:
>> Currently it looks like this:
>> ver001->ver002->ver003->...-verN
>> That's what t_ctid does now, right? Well, that's sort of stupid. Why not
>> have it do this:
>> ver001->verN->...->ver003->ver002->|
> Heh, because that's crazy.  The first time you insert a key into the
> index it will point to v1 of a tuple... say after 5 updates you have
> v2,v3,v4,v5... your c_tid pointer chain looks like v1
> (original)->v2->v3->v4-v5 (newest).  However, your whole idea is based
> on not having to do another index insert for unchanged keys, so the
> index still points to v1... which means you have to follow the c_tid
> chain to get to the newest version just like a sequential scan.  I
> don't see how you think you can reverse pointer it.

In the scenario, as previously outlined:


The index points to version 1 (ver001) which points to the latest version

>> This will speed up almost *all* queries when there are more than two
>> version of rows.
> Nope.

Of course it will.

>> When you vacuum, simply make the latest version (verN) the key row
>> (ver001).
> How are you going to do this without a ton of locking... remember, the
> index is pointing to v1 with a tid... so you'll have to physically
> move the newest version v5 to v1's tid from wherever it was... like a
> vacuum full on steroids.  Unless of course, you rebuild the index...
> but that's not a solution either.

I don't understand how you can assume this. In fact, it wil proably reduce
locking and disk IO by not having to modify indexes.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to