On Thu, Aug 4, 2016 at 09:53:31PM -0300, Claudio Freire wrote: > It's the other way around. A WARM chain has to span whole HOT chains. > The WARM chain always begins in the head of a HOT chain (or non-HOT > tuple of course), and cannot end before the HOT chain ends. > > That is, all within a single page: > > [ v1 .. v2 .. v3 .. v4 .. v5 .. v6 v7 ] > [ hot chain 1 ][ hot chain 2 ] [NH] > [ WARM CHAIN ] [NW] > > (NH = non-HOT) > (NW = non-WARM) > > The flag could be useful for the upgrade path, but if you ignore > having to live with old-format indexes, it's not necessary. > > A WARM chain starts at any index item pointer. It ends when there's a > key change or a page change (ie: the WARM chain cannot span multiple > pages). That cannot happen within a HOT chain, so that point will also > be the end of a HOT chain. > > You can think of a WARM chain as a chain of HOT chains.
OK, that's a lot of text, and I am confused. Please tell me the advantage of having an index point to a string of HOT chains, rather than a single one? Is the advantage that the index points into the middle of the HOT chain rather than at the beginning? I can see some value to that, but having more ctid HOT headers that can't be removed except by VACUUM seems bad, plus the need for index rechecks as you cross to the next HOT chain seems bad. The value of WARM is to avoid index bloat --- right now we traverse the HOT chain on a single page just fine with no complaints about speed so I don't see a value to optimizing that traversal, and I think the key rechecks and ctid bloat will make it all much slower. It also seems much more complicated. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
