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
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 |