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

From Amit Kapila
Subject Re: Heap WARM Tuples - Design Draft
Date
Msg-id CAA4eK1KLSyuoiONGzNTCOuyWey6bS898KoHSYA==uVTjvfVuhg@mail.gmail.com
Whole thread Raw
In response to Re: Heap WARM Tuples - Design Draft  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Aug 8, 2016 at 9:56 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, Aug  8, 2016 at 06:34:46PM +0530, Amit Kapila wrote:
>> I think here expensive part would be recheck for the cases where the
>> index value is changed to a different value (value which doesn't exist
>> in WARM chain).   You anyway have to add the new entry (key,TID) in
>> index, but each time traversing the WARM chain would be an additional
>> effort.  For cases, where there are just two index entries and one
>> them is being updated, it might regress as compare to what we do now.
>
> Yes, I think the all-increment or all-decrement WARM chain is going to
> be the right approach.
>

Probably, it will mitigate the cost in some cases, still there will be
a cost in comparisons especially when index is on char/varchar
columns.   Also, I think it will reduce the chance of performing WARM
update in certain cases considering we can create a WARM tuple only
when it follows the order.  OTOH, if we store pointers in index to
intermediate tuples, we won't face such issues.  Yes, there will be
some delay in cleanup of intermediate line pointers, however I think
we can clear those once we mark the corresponding index tuples as dead
in the next scan on corresponding index.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Venkata Balaji N
Date:
Subject: Re: Surprising behaviour of \set AUTOCOMMIT ON
Next
From: Michael Paquier
Date:
Subject: Re: multivariate statistics (v19)