On 2013-10-25 10:18:27 -0400, Tom Lane wrote:
> I think the right way to attack it is to create some way for a Datum
> value to indicate, at runtime, whether it's a flat value or an in-memory
> representation. Any given function returning the type could choose to
> return either representation. The datatype would have to provide a way
> to serialize the in-memory representation, when and if it came time to
> store it in a table. To avoid breaking functions that hadn't yet been
> taught about the new representation, we'd probably want to redefine the
> existing DETOAST macros as also invoking this datatype flattening
> function, and then you'd need to use some new access macro if you wanted
> visibility of the non-flat representation. (This assumes that the whole
> thing is only applicable to toastable datatypes, but that seems like a
> reasonable restriction.)
That sounds reasonable, and we have most of the infrastructure for it
since the "indirect toast" thing got in.
> Another thing that would have to be attacked in order to make the
> plpgsql-variable case work is that you'd need some design for copying such
> Datums in-memory, and perhaps a reference count mechanism to optimize away
> unnecessary copies. Your idea of tying the optimization to the nested
> function call scenario would avoid the need to solve this problem, but
> I think it's too narrow a scope to justify all the other work that'd be
> involved.
I've thought about refcounting Datums several times, but I always got
stuck when thinking about how to deal memory context resets and errors.
Any ideas about that?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
