Re: [HACKERS] Everything leaks; How it mm suppose to work?
От | dg@illustra.com (David Gould) |
---|---|
Тема | Re: [HACKERS] Everything leaks; How it mm suppose to work? |
Дата | |
Msg-id | 9804090748.AA03441@hawk.illustra.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Everything leaks; How it mm suppose to work? (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Everything leaks; How it mm suppose to work?
Re: [HACKERS] Everything leaks; How it mm suppose to work? |
Список | pgsql-hackers |
Bruce: > Maurice: > > >Running postgresql in interactive mode shows that for each query I > > >type there is memory lost. The exact amount of memory lost depends on > > >the query I use. The amount of memory not freed is also a function > > >of the number of tuples returned. > > > > > > > Oops, it seems some palloced memory is not freed by pfree but > > using some other function(s). > > My mistake, sorry. > > > > One thing I have found is that: > > select * from test where 1=0; > > do not leak memory while > > select * from test where x=-999; > > does leak memory, even though neither returns any rows. Strange. Would > seem to point to the optimizer or executor. In the first case, the where clause is constant and evaluates false, so not much is done. In the second case, the table is scanned and presumably some memory is allocated for each row, probably to evaluate the expression. Since this memory is allocated into a per statement duration, it will not be freed until the end of the statement when the context is destroyed. -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 - Linux. Not because it is free. Because it is better.
В списке pgsql-hackers по дате отправления: