Re: [HACKERS] psql & query string length - Mailing list pgsql-hackers

From Mike Mascari
Subject Re: [HACKERS] psql & query string length
Date
Msg-id 19990721140712.14964.rocketmail@web107.yahoomail.com
Whole thread Raw
List pgsql-hackers
In implementing a core Text C++ class object, 
we use realloc() without problems.  However, with
regard to resizing, we always DOUBLE the existing
size of the buffer when the string needs to be 
expanded so that it doesn't take 100 iterations
(and therefore 100 realloc()'s) to create an 800K
buffer.

Hope this helps, 

M. Mascari

--- "Ansley, Michael" <Michael.Ansley@intec.co.za>
wrote:
> Hi,
> 
> Well, I got psql to do it's thing, eventually.  I've
> tested it for pretty
> much everything, including \e, \g, \r, \i.  
> The one problem that I have had is that after about
> the third '\i long.sql',
> I get a core dump, because sprintf moaned about
> string size complications.
> The way I have structured it, memory is reallocated
> (re- malloc'd, not
> realloc'd) every time the query is extended.  I
> suspect that this is very
> inefficient, and probably causing the system to
> hooch after loading long.sql
> three times.  The main thought that I have had is to
> extend the query buffer
> in blocks of about 8k or 16k.  I presume that once
> working with set memory
> sizes, the memory usage will be substantially more
> efficient.  Ideas?
> 
> Also, what's the deal with realloc?  I tried it a
> couple of times, but it
> really screwed me around (hence the re- malloc'ing).
>  Or is it just a Bad
> Move to use realloc?
> 
> MikeA
> 
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: inheritance
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Another reason to redesign querytree representation