Re: Heap WARM Tuples - Design Draft
От | Andres Freund |
---|---|
Тема | Re: Heap WARM Tuples - Design Draft |
Дата | |
Msg-id | 20160804171728.c3da4dlmxoxuh6ud@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Heap WARM Tuples - Design Draft (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Heap WARM Tuples - Design Draft
|
Список | pgsql-hackers |
On 2016-08-04 18:11:17 +0100, Simon Riggs wrote: > On 4 August 2016 at 17:31, Andres Freund <andres@anarazel.de> wrote: > > Hi, > > > > On 2016-08-04 16:29:09 +0530, Pavan Deolasee wrote: > >> Indexes whose values do not change do not require new index pointers. Only > >> the index whose key is being changed will need a new index entry. The new > >> index entry will be set to the CTID of the root line pointer. > > > > That seems to require tracing all hot-chains in a page, to actually > > figure out what the root line pointer of a warm-updated HOT tuple is, > > provided it's HOT_UPDATED itself. Or have you found a smart way to > > figure that out? > > Hmm, sorry, I did think of that point and I thought I had added it to the doc. > > So, yes, I agree - re-locating the root is the biggest downside to > this idea. Perhaps Pavan has other thoughts? > > I think its doable, but it will be fiddly. I'm less afraid of the fiddlyness of finding the root tuple, than the cost. It's not cheap to walk through, potentially, all hot chains to find the root ctid. Have you considered what it'd take to allow index pointers to allow to point to "intermediate" root tuples? I.e. have some indexes point into the middle of an update-chain, whereas others still point to the beginning? There's certainly some complications involved with that, but it'd also have the advantage in reducing the amount of rechecking that needs to be done.
В списке pgsql-hackers по дате отправления: