Thread: MAX Query length

Trawling through the code last night I noticed that:
#define MAX_QUERY_SIZE (BLCKSZ * 2)

Is there any conceivable reason why the query length would be dependent on
the block size?  Or do I just have old source code?

MikeA

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> Trawling through the code last night I noticed that:
> #define MAX_QUERY_SIZE (BLCKSZ * 2)

> Is there any conceivable reason why the query length would be dependent on
> the block size?

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.

I don't know how long that particular constant has been defined like
that, though.  I had the idea that it was the same as BLCKSZ, not 2x.
You may well find that frontend libpq is using a different value for
its buffer sizes than the backend is :-(
        regards, tom lane

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> 
> Trawling through the code last night I noticed that:
> #define MAX_QUERY_SIZE (BLCKSZ * 2)
> 
> Is there any conceivable reason why the query length would be dependent on
> the block size?  Or do I just have old source code?

No great reason, but is seems like a good maximum.  This controls the
buffer size on the client and server.  Do you need it larger?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

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

Bernard Frankpitt <frankpit@pop.dn.net> writes:
> Tom Lane wrote:
>> 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.

> Perhaps it would be a good idea to increase
> the multiplier in 
>     #define MAX_QUERY_SIZE (BLCKSZ * 2)
> to something larger than 2.

This entire chain of logic will fall to the ground anyway once we support
tuples larger than a disk block, which I believe is going to happen
before too much longer.  So, rather than argue about what the multiplier
ought to be, I think it's more productive to just press on with making
the query buffers dynamically resizable...
        regards, tom lane

Tom Lane wrote:

>
> Bernard Frankpitt <frankpit@pop.dn.net> writes:
> > Tom Lane wrote:
> >> 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.
>
> > Perhaps it would be a good idea to increase
> > the multiplier in
> >     #define MAX_QUERY_SIZE (BLCKSZ * 2)
> > to something larger than 2.
>
> This entire chain of logic will fall to the ground anyway once we support
> tuples larger than a disk block, which I believe is going to happen
> before too much longer.  So, rather than argue about what the multiplier
> ought to be, I think it's more productive to just press on with making
> the query buffers dynamically resizable...

    Yes,  even  if we choose to make some other limit (like Vadim
    suggested around 64K), a query operating  on  them  could  be
    much  bigger.   I  already had some progress with a data type
    that uses a simple, byte oriented lz  compression  buffer  as
    internal representation.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #