Re: Detection of nested function calls
От | Andres Freund |
---|---|
Тема | Re: Detection of nested function calls |
Дата | |
Msg-id | 20131025144812.GC5627@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Detection of nested function calls (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Detection of nested function calls
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: