On Fri, Nov 25, 2016 at 11:23 PM, Bruce Momjian <br...@momjian.us> wrote: > On Thu, Nov 24, 2016 at 12:23:28PM -0500, Robert Haas wrote: >> I agree up to a point. I think we need to design our own system as >> well as we can, not just copy what others have done. For example, the >> design I sketched will work with all of PostgreSQL's existing index >> types. You need to modify each AM in order to support in-place >> updates when a column indexed by that AM has been modified, and that's >> probably highly desirable, but it's not a hard requirement. > > I feel you are going to get into the problem of finding the index entry > for the old row --- the same thing that is holding back more aggressive > WARM updates. >
I think I see a problem in that regards when the index column in updated twice with the same value. For example, table - test_undo(c1 int, c2 char(10)); index - idx_tu on test_undo(c1); Step-1 Insert (2, 'abc') Heap - 2, abc Index - 2 Commit; Step -2 Update (3,def) where c1 = 2; Heap - 3, def Index - 3 (another value will be 2) Undo - 2, abc Commit; At this point a new query which scans the index for value 2 will reach to the tuple (3,def). As scan started after all commits, tuple (3,def) appears okay, but it can compare the key value in the tuple to detect that this is not the right tuple. So, all is well till here. Step -3 Update (2) where c1 = 3; Heap - 2, def Index - 2 (another values will be 3,2) Undo - 3; Commit At this point, index scan for value 2 will find index tuple of step-1 (2) and will conclude 2,def as a right tuple, but actually, that is wrong as the step-1 (2) index tuple should not be visible to the user. Do you also this as a problem or am I missing something? If this a problem, then I think we need some form of delete marking system for the index, probably transaction visibility information as well. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
