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