Re: [HACKERS] aggregation memory leak and fix

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: riedel+(at)CMU(dot)EDU (Erik Riedel)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] aggregation memory leak and fix
Date: 1999-03-20 02:33:33
Message-ID: 199903200233.VAA11816@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 other than months and
* years */
int4 month; /* months and years, after time 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-03-20 04:07:04 Re: [HACKERS] One more globe
Previous Message Bruce Momjian 1999-03-20 02:07:01 Re: [HACKERS] aggregation memory leak and fix