Re: BRIN vs. HOT

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BRIN vs. HOT
Date: 2016-07-28 16:27:17
Message-ID: 20160728162717.GA386184@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Oh, I had a note to get back to the topic of HOT updates and it fell
through the cracks :-( You're right, this needs to be addressed.

> If the
> 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.

Sounds reasonable.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-07-28 17:57:59 Re: [Patch] RBTree iteration interface improvement
Previous Message Petr Jelinek 2016-07-28 15:20:06 Re: BRIN vs. HOT