"Tom Lane" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Ivar" <[EMAIL PROTECTED]> writes: > > Are there any real pefrormance difference, what are actual difference(%), > > have somebody measured even it ? > > You still haven't looked at the thread you were pointed to, have you? > > There is another issue besides disk space and performance, which is that > functions with large numbers of positional parameters are just plain bad > style --- it's way too easy to introduce bugs by passing the parameters > in the wrong order. It's usually better to coalesce some of the > parameters into arrays or records. Our awareness of this fact keeps us > from wanting to expend lots of work or resources on making the standard > function argument limit larger. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] >
I found some threads now: Seems there is big fuss around this. Table sizes are increasing ok, complaining IO penaly, but no reallife speed panalty size (%) http://groups.google.com/groups?q=FUNC_MAX_ARGS&start=20&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=10867.1018048699%40sss.pgh.pa.us&rnum=28 { "Josh Berkus" <[EMAIL PROTECTED]> writes: > Tom, >> I was surprised that people were dissatisfied with 16 (it was 8 not >> very long ago...). Needing more strikes me as a symptom of either bad >> coding practices or missing features of other sorts. > No, not really. It's just people wanting to use PL/pgSQL procedures as > data filters. For example, I have a database with complex > dependancies and validation rules that I started under 7.0.3, when > RULES were not an option for such things and triggers were harder to > write. As a result, I have the interface push new records for, say, > the CLIENTS table through a PL/pgSQL procedure rather than writing to > the table directly. Since the table has 18 columns, I need (18 + 2 > for session & user) 20 parameters for this procedure. There is another reallife situation where is needed more args. (Basically functions can't be used for INSERT) } > in the wrong order. It's usually better to coalesce some of the > parameters into arrays or records. How you pass array from c# though odbc to sql server ??? Seems I must wait some time, I'm sure that this limit is removed future releases. Just curious how other servers handle this ? MS SQL defenitely works Orcale ?? Db2 ?? SAP DB, works Firebird ?? "Ivar" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > Did you even bother to look at the thread I referred to? > What thread ? > You just gave some notes how to come over this, but I think I'll never use > modified source > and not standard release server. > > If you see my example of my functions (trying to move ms sql to postgre, all > goes well except it), > is them really so dummy or bad design. > > > greater than 32 arguments why they should suffer a performance hit just > > because you do. > Are there any real pefrormance difference, what are actual difference(%), > have somebody measured even it ? > > "Joe Conway" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Ivar wrote: > > > I don't see why default is so small. > > > > > > > Did you even bother to look at the thread I referred to? > > > > There was a lengthy discussion on the pros and cons of various default > > settings, and the consensus of the community was 32. If you'd like to > > make a cogent argument for why it ought to be higher, by all means do > > so. But you'll have to convince quite a few people who have no need for > > greater than 32 arguments why they should suffer a performance hit just > > because you do. > > > > Joe > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://archives.postgresql.org > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]