Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 6D813475A24 for ; Tue, 16 Apr 2002 00:14:32 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3G4DVF09113; Tue, 16 Apr 2002 00:13:31 -0400 (EDT) To: Neil Conway Cc: "Christopher Kings-Lynne" , peter_e@gmx.net, pgman@candle.pha.pa.us, josh@agliodbs.com, jproctor@prium.net, pgsql-patches@postgresql.org Subject: Re: [SQL] 16 parameter limit In-reply-to: <20020415235216.5bdf393a.nconway@klamath.dyndns.org> References: <20020415235216.5bdf393a.nconway@klamath.dyndns.org> Comments: In-reply-to Neil Conway message dated "Mon, 15 Apr 2002 23:52:16 -0400" Date: Tue, 16 Apr 2002 00:13:31 -0400 Message-ID: <9110.1018930411@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200204/164 X-Sequence-Number: 3679 Neil Conway writes: > My vote is to set the default # of function args to some > reasonable default (32 sounds good), and leave it at that. Bear in mind that s/32/16/ gives you the exact state of the discussion when we raised the limit from 8 to 16 ;-) Still, I do not really see the value of adding a configure argument. Anyone who can't figure out how to tweak this in pg_config.h is probably not ready to run a non-default configuration anyhow. If the consensus is to raise the default from 16 to 32, I won't object. Beyond that, I'd start asking questions about who's measured the performance hit and what they found. On the NAMEDATALEN part of the argument: SQL92 clearly expects that NAMEDATALEN should be 128. But the first report of the performance cost looked rather grim. Has anyone retried that experiment since we tweaked hashname to not hash all the trailing zeroes? regards, tom lane