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