On 2014-04-08 09:37:33 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-04-07 21:47:38 -0400, Tom Lane wrote:
> >> Well, that is certainly messy. I think you could just use a local
> >> HeapTupleData variable instead of palloc'ing every time, where "local"
> >> means "has lifespan similar to the slot pointer".
>
> >> There's some vaguely similar hacking near the end of ExecDelete.
>
> > Yea, and some other places. I wonder if a ExecShallowMaterializeSlot()
> > or something would be useful for me, that callsite and others?
>
> Don't like that name much, but I agree there's some room for a function
> like this.
I am not the biggest fan either, for one it's really rather long, for
another it's not really descriptive. One might think it's about toast or
something. Do you have a better name?
> I guess you're imagining that we'd add a HeapTupleData field
> to TupleTableSlots, and use that for the workspace when this situation
> arises?
I wasn't really sure about the approach yet. Either do something like
you describe (possibly reusing/recoining tts_minhdr?), or just allocate
a HeapTupleData struct.
> An alternative possibility would be to not invent a new function, but
> just make ExecStoreTuple do this unconditionally when shouldFree=false.
> Not sure if there'd be a noticeable runtime penalty.
I think that's a viable alternative.
> I know I've always thought
> of slots as being fully independent storage, and in this case they
> are not.
Me to. I was initially rather confused by the memory corruptions I was
seeing. I really thought that storing a tuple pointing to a buffer in
the slot should "just work".
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services