Re: Heap WARM Tuples - Design Draft - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Heap WARM Tuples - Design Draft
Date
Msg-id CAGTBQpZzeM6678ZfhwrahhW68SqLvO2CG-Y5GK0VU-gyXGQ1mQ@mail.gmail.com
Whole thread Raw
In response to Re: Heap WARM Tuples - Design Draft  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Aug 5, 2016 at 12:44 AM, Bruce Momjian <bruce@momjian.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).



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: PostgreSQL 10 Roadmaps
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu