| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> |
| Cc: | pgsql-interfaces(at)postgreSQL(dot)org |
| Subject: | Re: [INTERFACES] 8K query limit in 6.5? |
| Date: | 1999-07-13 15:46:08 |
| Message-ID: | 23258.931880768@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces |
"Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> writes:
> Why are these limits even an issue? Surely I should be able to adjust
> certain constants in the code (and this would include constants to take care
> of the tuple length) in order to adjust the performance of the system. I
> realise that life is not that simple, but perhaps it could be made simpler
> than it is now. At the moment, some of the constants used are pretty
> useless, because they can't really be adjusted.
> Can't we come up with a way to make this more amenable to adjustment?
If it bothers you, step right up and fix it ...
Where I was actually hoping to end up is with no fixed limit at all,
ie make all buffers for text be dynamically resizable to handle the
longest query presented in a given session. But it'd be a useful
intermediate step to find all the places that are dependent on max query
length and drive them all from a single config.h constant. All that
code would eventually be replaced, if we do dynamic sizing, but doing
this would still be helpful as a way of identifying everything that
needs to change. Just finding all the places that depend on max query
length is not as trivial as you might think.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-07-13 15:55:29 | Re: [INTERFACES] Three posts and no response 8--( |
| Previous Message | Daren Sefcik | 1999-07-13 15:23:32 | RE: [INTERFACES] Three posts and no response 8--( |