Re: [HACKERS] MAX Query length - Mailing list pgsql-hackers

From Bernard Frankpitt
Subject Re: [HACKERS] MAX Query length
Date
Msg-id 378CB314.E9B52FCC@pop.dn.net
Whole thread Raw
In response to Re: [HACKERS] MAX Query length  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] MAX Query length
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Updated TODO list
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Re: 6.5.1 release