Martijn van Oosterhout wrote:
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.
Yes.
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.
So, as I had mentioned before, you marshall as a *byte* stream
and not a *Datum* stream?
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.
<grin> Yes, I noticed. :> But it's hard for me to get this
"attitude" out of the way I approach a problem. :-(
(e.g., I wouldn't count people at a rally using a *float*! :>)
> 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.
Exactly. I could more "efficiently" replace postgres with
dedicated structures to do what I want. But, that ties my
implementation down to one less portable (and maintainable).
I'd go for INT32, it's most likely to be an "int" which should be "the
most natural size for the machine".
(sigh) Yes, I suppose so. Though it can have a big impact
on transport delays (server to client) if things really
are marshalled as byte streams, etc.
<shrug> I suppose I should just "do it" and let technology
catch up with my inefficiencies later!
Thanks!
--don
