On Wed, Sep 24, 2014 at 7:04 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Sep 19, 2014 at 2:54 PM, Peter Geoghegan <pg@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