Re: Heap WARM Tuples - Design Draft

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Heap WARM Tuples - Design Draft
Date: 2016-08-05 03:59:01
Message-ID: CAGTBQpZzeM6678ZfhwrahhW68SqLvO2CG-Y5GK0VU-gyXGQ1mQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 5, 2016 at 12:44 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> UPDATE t SET dat = dat + 1, id = 3, someid = 3 where id = 2;
>
> This is ends the WARM chain, and creates new index entries because all
> indexes are changed.
>
>> UPDATE t SET dat = dat + 1, id = 1, someid = 2 where id = 3;
>
> This does the same thing.
>
>> SELECT * FROM t WHERE someid = 2;
>
> This uses the 'someid' index. The index contains three entries:
>
> 1. {someid=2} pointing to first WARM chain
> 2. {someid=3} pointing to single tuple (no HOT chain)
> 3. {someid=2} pointing to single tuple (no HOT chain)
>
> The scan of #1 returns no visible rows. #2 doesn't match the value in
> the WHERE clause, so we don't even check the heap. The scan of #3
> returns one row.
>
> Remember, we don't scan past the end of the HOT chain, which is what we
> do now.

Ok, I botched the example.

I wanted the other updates to all be WARM updates, so imagine there's
another index that is unchanged (say, a someid2 not updated ever).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-08-05 03:59:06 Re: [COMMITTERS] pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu
Previous Message Bruce Momjian 2016-08-05 03:44:23 Re: Heap WARM Tuples - Design Draft