On Sat, Aug 6, 2016 at 10:51:21AM -0400, Bruce Momjian wrote:
> > If we need to find an efficient way to convert WARM chains back to HOT, which
> > will happen soon when the old index tuple retires, the system can attain a
> > stable state, not for all but many use cases.
>
> I don't see how that is possible, except perhaps by vacuum.
>
> OK, now I am less certain.
OK, crazy idea time --- what if we only do WARM chain additions when all
indexed values are increasing (with NULLs higher than all values)? (If
a key is always-increasing, it can't match a previous value in the
chain.) That avoids the problem of having to check the WARM chain,
except for the previous tuple, and the problem of pruning removing
changed rows. It avoids having to check the index for matching key/ctid
values, and it prevents CREATE INDEX from having to index WARM chain
values.
Any decreasing value would cause a normal tuple be created.
Sure, it is a limitation, but it removes almost all of the the overhead
of WARM updates. In fact, even the key comparisons of old/new tuples
will return -1, 0, or 1, and from there you can know if the new key is
unchanged, or increasing. I assume we already do this comparison to
determine if we can do a HOT update.
-- Bruce Momjian <bruce@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 +
