On Fri, Feb 24, 2017 at 2:42 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > Let's take an example. Say, we have a table (a int, b int, c text) and two > indexes on first two columns. > > H W > H > (1, 100, 'foo') -----> (1, 100, 'bar') ------> (1, 200, 'bar') -----> (1, > 200, 'foo') > > The first update will be a HOT update, the second update will be a WARM > update and the third update will again be a HOT update. The first and third > update do not create any new index entry, though the second update will > create a new index entry in the second index. Any further WARM updates to > this chain is not allowed, but further HOT updates are ok. > > If all but the last version become DEAD, HOT-prune will remove all of them > and turn the first line pointer into REDIRECT line pointer.
So, when you do the WARM update, the new index entries still point at the original root, which they don't match, not the version where that new value first appeared? I don't immediately see how this will work with index-only scans. If the tuple is HOT updated several times, HOT-pruned back to a single version, and then the page is all-visible, the index entries are guaranteed to agree with the remaining tuple, so it's fine to believe the data in the index tuple. But with WARM, that would no longer be true, unless you have some trick for that... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
