Thread

1. Re: [HACKERS] Everything leaks; How it mm suppose to work?

   Maurice Gittens <mgittens@gits.nl> — 1998-04-09T11:00:09Z

   >> 
   >
   >Does it make sense to have a 'row' context which is released just before
   >starting with a new tuple ? The total number or free is the same but they
   >are distributed over the query and unused memory should not accumulate.
   >I have seen backends growing to 40-60MB with queries which scan a very
   >large number of rows.
   >
   
   
   I think this would be appropiate.
   
   With regards from Maurice.
   
   
   

2. Re: [HACKERS] Everything leaks; How it mm suppose to work?

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-04-09T13:00:24Z

   > >Does it make sense to have a 'row' context which is released just 
   > >before starting with a new tuple ? The total number or free is the 
   > >same but they are distributed over the query and unused memory should 
   > >not accumulate.
   > >I have seen backends growing to 40-60MB with queries which scan a 
   > >very large number of rows.
   > I think this would be appropiate.
   
   It seems that the CPU overhead on all queries would increase trying to
   deallocate/reuse memory during the query. There are lots of places in
   the backend where memory is palloc'd and then left lying around after
   use; I had assumed it was sort-of-intentional to avoid having extra
   cleanup overhead during a query.
   
                        - Tom
   
   

3. Re: [HACKERS] Everything leaks; How it mm suppose to work?

   Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-04-09T14:55:05Z

   Thomas G. Lockhart wrote:
   > 
   > > >Does it make sense to have a 'row' context which is released just
   > > >before starting with a new tuple ? The total number or free is the
   > > >same but they are distributed over the query and unused memory should
   > > >not accumulate.
   > > >I have seen backends growing to 40-60MB with queries which scan a
   > > >very large number of rows.
   > > I think this would be appropiate.
   > 
   > It seems that the CPU overhead on all queries would increase trying to
   > deallocate/reuse memory during the query. There are lots of places in
   > the backend where memory is palloc'd and then left lying around after
   > use; I had assumed it was sort-of-intentional to avoid having extra
   > cleanup overhead during a query.
   
   This problem (introduced in 6.3) is already fixed by Bruce - will be
   in 6.3.2
   
   Vadim
   
   

4. Re: [HACKERS] Everything leaks; How it mm suppose to work?

   David Gould <dg@illustra.com> — 1998-04-09T18:34:00Z

   Thomas G. Lockhart replies to Maurice:
   > > >Does it make sense to have a 'row' context which is released just 
   > > >before starting with a new tuple ? The total number or free is the 
   > > >same but they are distributed over the query and unused memory should 
   > > >not accumulate.
   > > >I have seen backends growing to 40-60MB with queries which scan a 
   > > >very large number of rows.
   > > I think this would be appropiate.
   > 
   > It seems that the CPU overhead on all queries would increase trying to
   > deallocate/reuse memory during the query. There are lots of places in
   > the backend where memory is palloc'd and then left lying around after
   > use; I had assumed it was sort-of-intentional to avoid having extra
   > cleanup overhead during a query.
   
   This is exactly right. Destroying a memory context in the current
   implementationis a very high overhead operation. Doing it once per row
   would be a performance disaster.
   
   -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.