Hi, On 2018-04-21 14:16:27 +0100, Andrew Gierth wrote: > >>>>> "Amit" == Amit Kapila <amit.kapil...@gmail.com> writes: > > Amit> (c) Change the logic during rewrite such that it can detect this > Amit> situation and skip copying the tuple in the main table, > > So I dug into this one and it looks to me like the best approach. Here's > a draft patch against 10-stable, if nobody can think of any showstoppers > then I'll do the rest of the versions and commit them.
Please wait for a bit. This isn't a trivial change, and I would like to wrap my head around it. At the very least this seems like it could cause extreme slowdowns for large tables that have the right update/delete patterns? > + /* > + * OldestXmin going backwards can mean we have a RECENTLY_DEAD > row that > + * contains toast pointers whose toast rows have already been > vacuumed > + * away (or in the worst but unlikely case, recycled). If so, > then the > + * row must really be dead to all snapshots that could access > it, so > + * treat it as DEAD instead. > + */ How is it guaranteed that the recheck doesn't find a different toast tuple at the relevant position? Greetings, Andres Freund
