Re: Detection of nested function calls

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Hugo Mercier <hugo(dot)mercier(at)oslandia(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Detection of nested function calls
Date: 2013-10-28 16:42:28
Message-ID: 5673.1382978548@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias Schmitt 2013-10-28 16:45:18 Re: Darwin: make check fails with "child process exited with exit code 134"
Previous Message Tom Lane 2013-10-28 16:39:03 Re: Darwin: make check fails with "child process exited with exit code 134"