Subject: MAX Query length

From: "Ansley, Michael" <[email-masked]>
Date: Wed, 14 Jul 1999 09:48:01 +0200

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

---

From: Tom Lane <[email-masked]>
Date: Wed, 14 Jul 1999 10:16:43 -0400

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 14 Jul 1999 11:02:23 -0400 (EDT)

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> 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
  [email-masked]            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---

From: Bernard Frankpitt <[email-masked]>
Date: Wed, 14 Jul 1999 15:56:04 +0000

> 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 

to something larger than 2.

Bernie Frankpitt

---

From: Tom Lane <[email-masked]>
Date: Wed, 14 Jul 1999 12:02:08 -0400

> Perhaps it would be a good idea to increase
> the multiplier in 

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

---

From: [email-masked] (Jan Wieck)
Date: Thu, 15 Jul 1999 10:36:16 +0200 (MET DST)

> 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.                                  #
#========================================= [email-masked] (Jan Wieck) #