Re: [HACKERS] aggregation memory leak and fix

> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, 
> sum(l_extendedprice) as sum_base_price, 
> sum(l_extendedprice*(1-l_discount)) as sum_disc_price, 
> sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge, 
> avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, 
> avg(l_discount) as avg_disc, count(*) as count_order 
> from lineitem 
> where l_shipdate <= ('1998-12-01'::datetime - interval '90 day')::date 
> group by l_returnflag, l_linestatus 
> order by l_returnflag, l_linestatus;


OK, I have researched this.  I think you will find that:
('1998-12-01'::datetime - interval '90 day')::date 

is the cause.  In datetime_mi(), you will see:    dt1 = *datetime1;    dt2 = *datetime2;        result =
palloc(sizeof(TimeSpan));                   ^^^^^^    if (DATETIME_IS_RELATIVE(dt1))        dt1 = SetDateTime(dt1);
if(DATETIME_IS_RELATIVE(dt2))        dt2 = SetDateTime(dt2);
 

This obviously shows us allocating a return value, that probably is not
free'ed until the end of the query.  TimeSpan is:    typedef struct{    double      time;           /* all time units
otherthan months and                                 * years */    int4        month;          /* months and years,
aftertime for                                 * alignment */} TimeSpan;
 

Now, we certainly could pre-compute this constant once before doing the
query, but we don't, and even if we did, this would not fix the case
where a Var is involved in the expression.

When we grab values directly from tuples, like Var, the tuples are
auto-free'ed at the end, because they exist in tuple that we track. 
Values computed inside very deep functions are tough for us to free.  In
fact, this could be a very complex expression, with a variety of
temporary palloc'ed values used during the process.

My only quick solution would seem to be to add a new "expression" memory
context, that can be cleared after every tuple is processed, clearing
out temporary values allocated inside an expression.  This probably
could be done very easily, because the entry/exit locations into the
expression system are very limited.

Ideas people?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026