| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, josh(at)agliodbs(dot)com, jproctor(at)prium(dot)net, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCHES] [SQL] 16 parameter limit |
| Date: | 2002-04-16 05:01:33 |
| Message-ID: | 9406.1018933293@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches pgsql-sql |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> How about this: We store the first 16 parameters in some fixed array for
> fast access like now, and when you have more than 16 then 17 and beyond
> get stored in some variable array in pg_proc.
<<itch>> What's this going to cost us in the function lookup code paths?
If we can do it with little or no performance cost (at least for the
"normal case" of fewer-than-N parameters) then I'm all ears.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Curt Sampson | 2002-04-16 05:05:25 | Re: Importing Large Amounts of Data |
| Previous Message | Josh Berkus | 2002-04-16 04:50:21 | Re: [SQL] 16 parameter limit |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-04-16 05:06:50 | Re: [PATCHES] [SQL] 16 parameter limit |
| Previous Message | Josh Berkus | 2002-04-16 04:50:21 | Re: [SQL] 16 parameter limit |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-04-16 05:06:50 | Re: [PATCHES] [SQL] 16 parameter limit |
| Previous Message | Josh Berkus | 2002-04-16 04:50:21 | Re: [SQL] 16 parameter limit |