Re: Frequent Update Project: Design Overview of HOT Updates

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: josh(at)agliodbs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Subject: Re: Frequent Update Project: Design Overview of HOT Updates
Date: 2006-11-10 02:24:28
Message-ID: 2e78013d0611091824w77b7898fw9ad1bd466d223a2e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/10/06, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
> Tom,
>
> > Actually, you omitted to mention the locking aspects of moving tuples
> > around --- exactly how are you going to make that work without breaking
> > concurrent scans?
>
> I believe that's the "unsolved technical issue" in the prototype, unless
> Pavan has solved it in the last two weeks. Pavan?
>
>
When an overflow tuple is copied back to the main heap, the overflow tuple
is
marked with a special flag (HEAP_OVERFLOW_MOVEDBACK). Subsequently,
when a backend tries to lock the overflow version of the tuple, it checks
the flag
and jumps to the main heap if the flag is set.

We use the same technique to update the correct version of a tuple when a
tuple is moved back to the main heap.

Regards,
Pavan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-11-10 05:27:48 Re: Frequent Update Project: Design Overview of HOT Updates
Previous Message Andrew Dunstan 2006-11-10 01:48:30 Re: plperl/plperlu interaction