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-08 20:24:30
Message-ID: 20160808202430.GG16416@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 8, 2016 at 03:36:12PM -0300, Claudio Freire wrote:
> I think I prefer a more thorough approach.
>
> Increment/decrement may get very complicated with custom opclasses,
> for instance. A column-change bitmap won't know how to handle
> funcional indexes, etc.

Hot does HOT handle them? If it does, it has to look at all the columns
passes to the expression index, so it seems to be the same amount of
work.

> What I intend to try, is modify btree to allow efficient search of a
> key-ctid pair, by adding the ctid to the sort order. Only inner pages
> need to be changed, to include the ctid in the pointers, leaf pages
> already have the ctid there, so they don't need any kind of change. A
> bit in the metapage could indicate whether it's a new format or an old
> one, and yes, only new indices will be able to use WARM.
>
> But with efficient key-ctid searches, you handle all cases, and not
> just a few common ones.

True. I am worried about page spills caused by having to insert a rows
into an existing page and and index entry having to be pushed to an
adjacent page to maintain ctid index order.

--
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 Claudio Freire 2016-08-08 20:36:13 Re: Heap WARM Tuples - Design Draft
Previous Message Bruce Momjian 2016-08-08 20:19:08 Re: Heap WARM Tuples - Design Draft