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-24 06:11:56
Message-ID: 199903240611.BAA01206@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> --
> -- Query 1
> --
> 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;
>
>
> when I run this against 6.4.2, the postgres process grows to upwards of
> 1 GB of memory (at which point something overflows and it dumps core) -
> I watch it grow through 200 MB, 400 MB, 800 MB, dies somewhere near 1 GB
> of allocated memory).
>

Here is my first attempt at fixing the expression memory leak you
mentioned. I have run it through the regression tests, and it seems to
be harmless there.

I am interested to see if it fixes the expression leak you saw. I have
not committed this yet. I want to look at it some more.

--
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

Attachment Content-Type Size
unknown_filename text/plain 3.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Postgres mailing lists 1999-03-24 07:37:27 Really slow query on 6.4.2
Previous Message Erik Riedel 1999-03-24 05:13:13 Re: [HACKERS] longer-term optimizer musings