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).
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 |