Re: Detection of nested function calls

On 2013-10-28 12:42:28 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Oct 28, 2013 at 11:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> The idea I'm thinking about at the moment is that toast tokens of this
> >> sort might each contain a function pointer to the required flattening
> >> function.
>
> > This might be OK, but it bloats the in-memory representation. For
> > small data types like numeric that might well be significant.
>
> Meh. If you don't include a function pointer you will still need the OID
> of the datatype or the decompression function, so it's not like omitting
> it is free.

That's what I thought at first too - but I am not sure it's actually
true. The reason we need to include the toastrelid in varatt_externals
(which I guess you are thinking of, like me) is that we need to be able
to resolve "naked" Datums to their original value without any context.
But at the locations where we'd need to call the memory
representation->disk conversion function we should have a TupleDesc with
type information, so we could lookup the needed information there.

> In any case, the design target here is for data values that
> are going to be quite large, so an extra 4 bytes or whatever in the
> reference object doesn't really seem to me to be something to stress
> over.

I'd actually be happy if we can get this to work for numeric as well - I
have seen several workloads where that's a bottleneck. Not that I am
sure that the 8bytes for a pointer would be the problem there (in
contrast to additional typecache lookups).

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services