Обсуждение: Can't find docs on Postgresql.conf
Folks, I know there are full docs on postgresql.org somewhere detailing all of the postgresql.conf options. I can't find them ... only the limited set in the "runtime options" section. I'm looking for the option to change the number of parameters allowed for functions. -Josh ______AGLIO DATABASE SOLUTIONS___________________________ Josh Berkus Complete informationtechnology josh@agliodbs.com and data management solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit organizations. San Francisco
> Folks, > > I know there are full docs on postgresql.org somewhere detailing all of > the postgresql.conf options. I can't find them ... only the limited set > in the "runtime options" section. > > I'm looking for the option to change the number of parameters allowed > for functions. I don't think we have a configure option for the number of parameters. The number of params and the length of identifiers are two things we should increase in 7.3. In TODO we now have: * Increase identifier length (NAMEDATALEN) if small performance hit* Increase maximum number of function parameters -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The number of params and the length of identifiers are two things we
> should increase in 7.3.
> In TODO we now have:
> * Increase identifier length (NAMEDATALEN) if small performance hit
> * Increase maximum number of function parameters
We already *did* increase the standard max number of function
parameters, from 8 to 16, and that was just a couple or three versions
back. I don't recall hearing any groundswell of complaints to evidence
that very many people need it set higher.
NAMEDATALEN is a different story --- we do see complaints about that
fairly regularly.
regards, tom lane
"Josh Berkus" <josh@agliodbs.com> writes:
> I know there are full docs on postgresql.org somewhere detailing all of
> the postgresql.conf options. I can't find them ... only the limited set
> in the "runtime options" section.
> I'm looking for the option to change the number of parameters allowed
> for functions.
You're not finding it there because that's not where it is ;-)
You need to change config.h and rebuild and re-initdb, instead.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Seems we should increase to 24 or 32. Is there a
> downside to the increase. I can't even imagine a performance hit.
Darn if I know. We should try to measure it before assuming it's
insignificant. At the very least, it'd increase the size of pg_proc
by about a third ...
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The number of params and the length of identifiers are two things we > > should increase in 7.3. > > > In TODO we now have: > > > * Increase identifier length (NAMEDATALEN) if small performance hit > > * Increase maximum number of function parameters > > We already *did* increase the standard max number of function > parameters, from 8 to 16, and that was just a couple or three versions > back. I don't recall hearing any groundswell of complaints to evidence > that very many people need it set higher. I was talking to Ben Adida last week (OpenACS) and he mentioned they are having problems with the limit at 16, and it seems Josh is as well. Ben is doing some object-oriented function mechanism, and you know how that can eat parameters. Seems we should increase to 24 or 32. Is there a downside to the increase. I can't even imagine a performance hit. Comments? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Seems we should increase to 24 or 32. Is there a > > downside to the increase. I can't even imagine a performance hit. > > Darn if I know. We should try to measure it before assuming it's > insignificant. At the very least, it'd increase the size of pg_proc > by about a third ... Doesn't it store in pg_proc as an array, which is of variable length? I think the only overhead is adding code to fmgr.c for the extra param combinations. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Doesn't it store in pg_proc as an array, which is of variable length?
No, it's *fixed* length. Increasing FUNC_MAX_ARGS translates directly
to wasted space.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Doesn't it store in pg_proc as an array, which is of variable length? > > No, it's *fixed* length. Increasing FUNC_MAX_ARGS translates directly > to wasted space. Oh, I see it now, it is our old friend 'oidvector'. Now I remember modifying that when we changed from 8 to 16. I have modified the TODO to say: * Increase maximum number of function parameters if little wasted space We can address this during 7.3. and decide if it is worth it. Maybe it isn't. My calculations show a change of proc params from 16 to 32 would increase tuple length for pg_proc change from 180 to 244 or a 35% increase. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Doesn't it store in pg_proc as an array, which is of variable length? > > No, it's *fixed* length. Increasing FUNC_MAX_ARGS translates directly > to wasted space. If we increase it from 16 to 24, that changes from 180 to 212 or a 17% increase. That may be a reasonable default. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, Nov 06, 2001 at 07:21:09PM -0500, Bruce Momjian wrote: > > I was talking to Ben Adida last week (OpenACS) and he mentioned they are > having problems with the limit at 16, and it seems Josh is as well. Ben > is doing some object-oriented function mechanism, and you know how that > can eat parameters. Seems we should increase to 24 or 32. Is there a > downside to the increase. I can't even imagine a performance hit. Indeed we (at OpenACS) could use more parameters. We are porting a zillion Oracle PL/SQL functions to Postgres, and in Oracle you can have optional parameters and default values. In PostgreSQL we have to overload functions to make up for the possible combinations. In this process, sometimes we run out of parameters and have to submit to more, errr, creative ways to get the job done. The %TYPE patch that was added to 7.2 will help us a lot. Thanks a bunch. -Roberto -- +----| http://fslc.usu.edu USU Free Software & GNU/Linux Club |------+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer Error finding REALITY.SYS - Universe halted.
> On Tue, Nov 06, 2001 at 07:21:09PM -0500, Bruce Momjian wrote: > > > > I was talking to Ben Adida last week (OpenACS) and he mentioned they are > > having problems with the limit at 16, and it seems Josh is as well. Ben > > is doing some object-oriented function mechanism, and you know how that > > can eat parameters. Seems we should increase to 24 or 32. Is there a > > downside to the increase. I can't even imagine a performance hit. > > Indeed we (at OpenACS) could use more parameters. > > We are porting a zillion Oracle PL/SQL functions to Postgres, and in > Oracle you can have optional parameters and default values. In PostgreSQL > we have to overload functions to make up for the possible combinations. > > In this process, sometimes we run out of parameters and have to submit to > more, errr, creative ways to get the job done. Good. Will 24 params be enough for you? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026