Re: Heap WARM Tuples - Design Draft

On Mon, Aug 8, 2016 at 9:56 PM, Bruce Momjian <bruce(at)momjian(dot)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