From: | Don Y <pgsql(at)DakotaCom(dot)Net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org, kleptog(at)svana(dot)org |
Subject: | Re: PG_RETURN_? |
Date: | 2006-05-02 18:13:31 |
Message-ID: | 4457A14B.8070708@DakotaCom.Net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Don Y | 2006-05-02 18:14:48 | Re: Return value (instead of reference) for user defined |
Previous Message | Florian G. Pflug | 2006-05-02 17:55:05 | Re: Using a pointer as statetype for an aggregate |