On Wed, Sep 24, 2014 at 7:04 PM, Peter Geoghegan <p...@heroku.com> wrote: > 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.
The top issue on my agenda is figuring out a way to get rid of the extra SortSupport object. I'm not going to commit any version of this patch that uses a second SortSupport for the tiebreak. I doubt anyone else will like that either, but you can try. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
