Martijn van Oosterhout wrote:
On Fri, Sep 30, 2005 at 10:20:34AM -0500, Tony Caduto wrote:
Tom,
I hardly think the overhead would be significant on modern processors, I
don't think the majority of users are running on Pentium 90s.( I am
assuming you mean a performance overhead)
Um, please read the documention. Returning a tuple is *significantly*
more expensive than returning a single value. You have to get the tuple
descriptor, allocate memory for the tuple, fill in all the fields with
your data... For a single value you just return it.
See here for all the details, you really don't want to do it if you
don't need to.
http://www.postgresql.org/docs/8.0/interactive/xfunc-c.html#AEN30497
Now, you could fudge the parser to automatically alter the name of the
value in the function but I'm have no idea how hard that would be...
So you might notice little performance hit bringing back a million rows,
and most of these type of single OUT params functions only return one
row/value anyway.
There would be zero perceivable difference in performance regardless of
the extra overhead for a single value/row.
As a application developer, I don't care about tuples etc, I just want
it to work as expected without having to
resort to hacks like creating a second OUT param that is not used,
otherwise I would have to change a lot of client code where ever the OUT
param is refernced by name instead of position and that is done a lot
because the position is more likely to change than the name.
The bottom line(regardless of any overhead or if I read the docs about
returning a tuple) is that if you have a OUT param it should return that
name, not the name of the function, period.
Thanks,
Tony
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
