Re: BRIN vs. HOT

On 28/07/16 16:53, Robert Haas wrote:
> If I understand correctly, we currently deem an update to be non-HOT
> whenever any indexed column is updated.  This is because tuple
> versions created by HOT updates can later be removed by HOT pruning,
> which means that they must not be referenced by index entries.
> Otherwise, after HOT pruning removed the tuple, the index entries
> would at best be pointing at nothing and at worse be pointing at some
> completely unrelated tuple.
>
> But what about index types that do not store TIDs - i.e. BRIN?  If the

I was thinking about this as well when I've seem the Uber post.

> indexed column is updated, we can't actually create a Heap Only Tuple
> (HOT), because then the index might be wrong.  But we could create a
> Heap Mostly Tuple[1].  We'd construct the update chain in the heap
> page just as we would for HOT, and set all the same flags.  But then
> we'd also insert new index entries for any TID-free indexes, currently
> just BRIN.  For BRIN, that would have the effect of updating the
> summary data for that page in such a way that it would encompass both
> the old and new values.

I thought about adding another am api function to let index decide if 
update can be HOT or not, but I like you idea more.

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services