Re: [HACKERS] psql & query string length

Поиск
Список
Период
Сортировка
От Mike Mascari
Тема Re: [HACKERS] psql & query string length
Дата
Msg-id 19990721140712.14964.rocketmail@web107.yahoomail.com
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: inheritance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Another reason to redesign querytree representation