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 <robertmh...@gmail.com> writes: > > > On Mon, Oct 28, 2013 at 11:12 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers