Re: B-Tree support function number 3 (strxfrm() optimization)

On Fri, Sep 19, 2014 at 2:54 PM, Peter Geoghegan <pg(at)heroku(dot)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