Re: Heap WARM Tuples - Design Draft

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
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-06 03:04:33
Message-ID: 20160806030433.GE26927@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote:
> So to summarize again:
>
> o chains start out as HOT
> o they become WARM when some indexes change and others don't
> o for multiple index changes, we have to check all indexes
> for key/ctid matches
> o for single index changes, we can fail HOT and create a new
> non-HOT/WARM tuple if there are too many index matches
> o 99% of index checks will not find a key/ctid match

I think a WARM chain where the the head ctid isn't LP_REDIRECT wasn't
pruned, so here is an updated list:

o chains start out as HOT
o they become WARM when some indexes change and others don't
o if WARM chain head is not LP_REDIRECT, check existing chain for key
matches
o if WARM chain head is LP_REDIRECT:
o for single index changes, we can fail HOT and create a new
non-HOT/WARM tuple if there are too many index matches
o for multiple index changes, we have to check all indexes
for key/ctid matches
o 99% of index checks will not find a key/ctid match

So, we are only checking the index if the WARM chain was pruned, and we
can bail out if there is only one index changed. This is looking more
doable.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-08-06 04:11:37 Re: "Some tests to cover hash_index"
Previous Message Peter Eisentraut 2016-08-06 01:43:48 Re: pg_ctl promote wait