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 по дате отправления: