On 2016-08-04 18:18:47 +0100, Simon Riggs wrote: > On 4 August 2016 at 18:17, Andres Freund <and...@anarazel.de> wrote: > > On 2016-08-04 18:11:17 +0100, Simon Riggs wrote: > > I'm less afraid of the fiddlyness of finding the root tuple, than the > > cost. It's not cheap to walk through, potentially, all hot chains to > > find the root ctid. > > > > Have you considered what it'd take to allow index pointers to allow to > > point to "intermediate" root tuples? I.e. have some indexes point into > > the middle of an update-chain, whereas others still point to the > > beginning? There's certainly some complications involved with that, but > > it'd also have the advantage in reducing the amount of rechecking that > > needs to be done. > > "Intermediate root tuples" was my first attempt at this and it didn't > work. I'll dig up the details, some problem in VACUUM, IIRC.
I think it's doable, but the question is how to do cleanup. It's kind of easy to end up with a page full of line pointers which are all reachable from indexes, but otherwise useless. But I'm not sure that's actually that inevitable: a) Given that we fully scan indexes anyway, we could apply redirections to the indexes themselves, during vacuum. Then redirections could be removed afterwards. b) Start fixing up indexes, by refinding entries in the index from the heap tuple. That requires expressions to actually be immutable, but personally I think it's stupid to cater for expressions that are not. Then we can update indexes to point to the "final tuple" after pruning. It'd also pave the way to avoid the full index scan at the end of vacuum (in some cases). Andres -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers