Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA24877 for ; Tue, 13 Jul 1999 11:47:06 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA23260; Tue, 13 Jul 1999 11:46:09 -0400 (EDT) To: "Ansley, Michael" cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] 8K query limit in 6.5? In-reply-to: Your message of Tue, 13 Jul 1999 17:11:15 +0200 <1BF7C7482189D211B03F00805F8527F70ED026@S-NATH-EXCH2> Date: Tue, 13 Jul 1999 11:46:08 -0400 Message-ID: <23258.931880768@sss.pgh.pa.us> From: Tom Lane "Ansley, Michael" 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