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
|
Список | 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 по дате отправления: