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

From Claudio Freire
Subject Re: Heap WARM Tuples - Design Draft
Date
Msg-id CAGTBQpZdO_ceiGmYmKc309x=0Nk6Dd5skTs6gQySghpmJJ6xmA@mail.gmail.com
Whole thread Raw
In response to Re: Heap WARM Tuples - Design Draft  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On Fri, Aug 5, 2016 at 9:21 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> On Fri, Aug  5, 2016 at 07:51:05PM -0300, Claudio Freire wrote:
>>> > This does create more HOT chains where the root ctid cannot be removed,
>>> > but it does avoid the index key/ctid check because any entry in the HOT
>>> > chain has identical keys.  What this would not handle is when an entire
>>> > HOT chain is pruned, as the keys would be gone.
>>>
>>> I believe the only solution is to use bitmap index scans with WARM indexes.
>>
>> Let me back up and explain the benefits we get from allowing HOT chains
>> to be WARM:
>>
>> *  no index entries for WARM indexes whose values don't change
>> *  improved pruning because the HOT/WARM chains can be longer because we
>>    don't have to break chains for index changes
>>
>> While I realize bitmap indexes would allow us to remove duplicate index
>> entries, it removes one of the two benefits of WARM, and it causes every
>> index read to be expensive --- I can't see how this would be a win over
>> doing the index check on writes.
>
> But the index check could be prohibitely expensive.

Well... it could be made efficient for the case of nbtree with a format change.

If nbtree sorted by tid as well, for instance.

But an upgrade there would involve a reindex before WARM can be applied.



pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Heap WARM Tuples - Design Draft
Next
From: Bruce Momjian
Date:
Subject: Re: Heap WARM Tuples - Design Draft