On Fri, Sep 19, 2014 at 2:54 PM, Peter Geoghegan <p...@heroku.com> wrote: > Probably not - it appears to make very little difference to > unoptimized pass-by-reference types whether or not datum1 can be used > (see my simulation of Kevin's worst case, for example [1]). Streaming > through a not inconsiderable proportion of memtuples again is probably > a lot worse. The datum1 optimization (which is not all that old) made > a lot of sense when initially introduced, because it avoided chasing > through a pointer for pass-by-value types. I think that's its sole > justification, though.
Just to be clear -- I am blocked on this. Do you really prefer to restart copying heap tuples from scratch in the event of aborting, just to make sure that the datum1 representation is consistently either a pointer to text, or an abbreviated key? I don't think that the costs involved make that worth it, as I've said, but I'm not sure how to resolve that controversy. I suggest that we focus on making sure the abort logic itself is sound. There probably hasn't been enough discussion of that. Once that is resolved, we can revisit the question of whether or not copying should restart to keep the datum1 representation consistent. I suspect that leaving that until later will be easier all around. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
