Re: [HACKERS] MAX Query length

Поиск
Список
Период
Сортировка
От Bernard Frankpitt
Тема Re: [HACKERS] MAX Query length
Дата
Msg-id 378CB314.E9B52FCC@pop.dn.net
обсуждение исходный текст
Ответ на Re: [HACKERS] MAX Query length  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] MAX Query length  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> 
> "Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> > Trawling through the code last night I noticed that:
> > #define MAX_QUERY_SIZE (BLCKSZ * 2)
> 
>
> Sure: you want to be able to INSERT a tuple of maximum size.  In the
> absence of dynamically sized text buffers, a reasonable estimate of
> the longest INSERT command of interest is going to depend on BLCKSZ.
...
>                         regards, tom lane

While I agree that it is reasonable that the query size should be
dependent on the block-size, there is an assumption here that the
type_in() and type_out() routines that do not expand the size of the
ascii representation of the tuple data in the query string to more than
twice is size in it's internal disk representation.  An important
exception to this assumption would be large arrays of floating point
data that are stored with limited precision.  A (single-precision) float
takes 4 bytes of space in a  disk  block, yet the ascii representation
for the same data before conversion could easily take in excess of 16
bits if it comes from a 
piece of code  like 
       double x;int buf_pos........buf_pos +=   snprintf( &query_buf[buf_pos], (l_buf - buf_pos ), "%e", x);  

somewhere in a front end.  Perhaps it would be a good idea to increase
the multiplier in 
   #define MAX_QUERY_SIZE (BLCKSZ * 2)


to something larger than 2.

Bernie Frankpitt


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Updated TODO list
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Re: 6.5.1 release