Re: [HACKERS] MAX Query length

From: Bernard Frankpitt <frankpit(at)pop(dot)dn(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] MAX Query length
Date: 1999-07-14 15:56:04
Message-ID: 378CB314.E9B52FCC@pop.dn.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-07-14 15:58:00 Re: Arrays versus 'type constant' syntax
Previous Message Ansley, Michael 1999-07-14 15:54:49 RE: [HACKERS] MAX Query length