Re: Detection of nested function calls

On Mon, Oct 28, 2013 at 05:48:55PM +0100, Andres Freund wrote:
> 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
>
With the type information available, you could have a single lookup table
per backend with the function pointer so the space would be negligible
amortized over all of the datums of each type.

Regards,
Ken