Re: [HACKERS] aggregation memory leak and fix

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] aggregation memory leak and fix
Дата
Msg-id 199903200207.VAA11424@candle.pha.pa.us
обсуждение исходный текст
Ответ на aggregation memory leak and fix  (Erik Riedel <riedel+@CMU.EDU>)
Список pgsql-hackers
> 
> Platform:  Alpha, Digital UNIX 4.0D
> Software:  PostgreSQL 6.4.2 and 6.5 snaphot (11 March 1999)
> 
> I have a table as follows:
> 
> Table    = lineitem
> +------------------------+----------------------------------+-------+
> |              Field     |              Type                | Length|
> +------------------------+----------------------------------+-------+
> | l_orderkey             | int4 not null                    |     4 |
> | l_partkey              | int4 not null                    |     4 |
> | l_suppkey              | int4 not null                    |     4 |
> | l_linenumber           | int4 not null                    |     4 |
> | l_quantity             | float4 not null                  |     4 |
> | l_extendedprice        | float4 not null                  |     4 |
> | l_discount             | float4 not null                  |     4 |
> | l_tax                  | float4 not null                  |     4 |
> | l_returnflag           | char() not null                  |     1 |
> | l_linestatus           | char() not null                  |     1 |
> | l_shipdate             | date                             |     4 |
> | l_commitdate           | date                             |     4 |
> | l_receiptdate          | date                             |     4 |
> | l_shipinstruct         | char() not null                  |    25 |
> | l_shipmode             | char() not null                  |    10 |
> | l_comment              | char() not null                  |    44 |
> +------------------------+----------------------------------+-------+
> Index:    lineitem_index_
> 
> that ends up having on the order of 500,000 rows (about 100 MB on disk).  
> 
> I then run an aggregation query as:
> 
> --
> -- 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;
> 

OK, I do have the query.  Please try removing the (1+l_tax) so it is
just l_tax, and change the 1998... to just a simple date string, and see
if the problem goes away.  If we can find something specific in the
query that is causing the memory over-allocation, it is that much easier
to find the cause.

Also, try removing all the arithmetic in the query or simplify the query
to see if there is a certain part that is causing it.  If it is really
an 8-byte issue, it must be very small indeed, and only visible because
you have so much data, and are attentive.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] aggregation memory leak and fix
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] 6.5 Features list