Обсуждение: RE: [INTERFACES] 8K query limit in 6.5?

Поиск
Список
Период
Сортировка

RE: [INTERFACES] 8K query limit in 6.5?

От
"Ansley, Michael"
Дата:
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?

Thoughts...

MikeA

>> -----Original Message-----
>> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> Sent: Tuesday, July 13, 1999 3:59 PM
>> To: Matthew Hagerty
>> Cc: pgsql-interfaces@postgreSQL.org
>> Subject: Re: [INTERFACES] 8K query limit in 6.5? 
>> 
>> 
>> Matthew Hagerty <matthew@venux.net> writes:
>> > Was the 8K query limit increased in 6.5?
>> 
>> Nope.
>> 
>> I tried to stir up some enthusiasm for fixing it in 6.6, but didn't
>> have much success --- too soon to say whether it will happen for 6.6
>> or be postponed again.
>> 
>>             regards, tom lane
>> 


Re: [INTERFACES] 8K query limit in 6.5?

От
Tom Lane
Дата:
"Ansley, Michael" <Michael.Ansley@intec.co.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