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