Forum OpenACS Development: PostgreSQL 7.1 functions can take more than 16 parameters
/* * Maximum number of columns in an index and maximum number of arguments * to a function. They must be the same value. * * The minimum value is 8 (index creation uses 8-argument functions). * There is no specific upper limit, although large values will waste * system-table space and processing time. * * CAUTION: changing these requires an initdb. * * BTW: if you need to call dynamically-loaded old-style C functions that * have more than 16 arguments, you will also need to add cases to the * switch statement in fmgr_oldstyle() in src/backend/utils/fmgr/fmgr.c. * But consider converting such functions to new-style instead... */ #define INDEX_MAX_KEYS 16 #define FUNC_MAX_ARGS INDEX_MAX_KEYS
This same parameter controls how many columns are allowed in an index.
I'd like to investigate this further, as there are obvious benefits to some packages. Does anyone know if there are any drawbacks to increasing this value?
If there aren't, then maybe we could ask the PG team to have the default set to something more than 16?
The default in PG hasn't changed, as you can see.
As far as asking folks to change it and compile their own PG, we did that in PG 6.5 and 7.0 in order to get blksize - and therefore maxiumum bboard post lengths etc - up to a reasonable figure.
But that's not necessary in PG 7.1, and we're now seeing more work in the way of pre-canned distributions with default values being installed on users machines. I think the argument against forcing a recompile for folks to use OpenACS has grown, not shrunk, since our first 3.x release.
It's unfortunate. I personally have a hard time believing that increasing the default value to 32 params/max colums to index would cause serious user problems in today's world of big PC's being sold for relatively small amounts of money.
But thus far the PG folk don't see it this way. Ironically, 16
parameters would've been considered to be extremely generous and forward-looking a few years ago, i.e. when it was chosen ...
OpenACS 4.x installers than porters...
Given the interest in "better out of box experience" in recent posts, forcing a PG recompile looks like a step in the wrong direction.
Is it worth re-asking the PG folks about this, ready for PG 7.2 or 7.3 or whatever ... so at least it could get onto their agenda for some (distant?) future PG version? In the 'many months' since it apparently first came up, hardware has got still faster and still cheaper, so maybe the case is now sufficiently strong?
I noticed that the %TYPE patch for PL/pgSQL was included in 7.2 because of community pressure (on which we played a role) and because the patch was good too, of course.
I wasn't proposing asking folks to compile custom-versions. That'd require an initdb and all. So I agree with Jonathan and you too.