Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-10-28 12:42:28 -0400, Tom Lane wrote:
>> 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.
I don't think that's a safe assumption at all. We need to be able to do
flattening anywhere PG_DETOAST_DATUM() can be called.
In any case, my point here is largely that I don't want to add a catalog
lookup to the operation. This whole proposal is basically about trading
greater short-term memory usage to gain speed, so griping about an extra 4
or so bytes per value seems to me to be missing the point completely.
Or to put it even more bluntly: if you've not realized that the extra
palloc overhead of an out-of-line instance of the datum will swamp what
we're talking about here, you need to realize that.
>> 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).
Yeah. The other point worth considering is that there will not likely be
all that many such values floating around at once, so even if there does
end up being a significant percentage bloat in the size of a non-flat
numeric, I doubt anyone will notice.
regards, tom lane