On Tue, May 02, 2006 at 10:06:19AM -0700, Don Y wrote: > >The type as declared determines the storage required to store it. That > > Yes, but for a function returning a value that does not exceed > sizeof(Datum), there is no *space* consequence. I would assume > most modern architectures use 32 bit (and larger) registers. When you return a Datum, it's always the same size. When you're returning a string, you're still returning a Datum, which may be 4 or 8 bytes depending on the platform. But what I was referring to was the space to store the data in a tuple on disk, or to send the data to a client. These are affected by the choice of representation. > OTOH, some machines incur a (tiny) penalty for casting char to long. > Returning INT32 *may* be better from that standpoint -- assuming > there is no added offsetting cost marshalling. Within the backend the only representations used are Datum and tuples. I don't think either of them would have a noticable difference between various pass-by-value formats. > ... I'd be annoyed to have > built dozens of functions ASSUMING "INT32" when a *better* > assumption might have been "CHAR"... (I'm working in an > embedded environment where "spare CPU cycles" mean you've > wasted $$$ on hardware that you don't need :-/ ) Hmm, postgres doesn't try to save on cycles. the philosophy is to get it right first, then make it fast. The entire fmgr interface is slower than the original design (old-style functions), but this design works on all platforms whereas the old one didn't. I'd go for INT32, it's most likely to be an "int" which should be "the most natural size for the machine". Have a nice day, -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment:
signature.asc
Description: Digital signature
