Re: High memory usage

From: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
To: Rainer Mager <rmager(at)vgkk(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: High memory usage
Date: 2001-06-20 15:35:55
Message-ID: 20010620103554.C1496@rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-jdbc pgsql-patches

Ranier -
Can you explain in words what this query is supposed to be doing?

I'm guessing, from the DISTINCT, and the use of multiple occurances of
the same table, that the result you want can be gotten at in some other
way, that lets the backend be smarter about how it does it. Since it _is_
releasing the memory, i.e., it's not a new leak, I'm guessing that Tom
just got a whole lot less interested ;-) But helping you use PostgreSQL
better is part of what the community does, as well.

Hmm, you mention that _planning_ this query sucks up the memory, as well.
My guess is it's an interaction of the optimizer with the plan for this
query, which might have many, nearly identical cost plans, since 8 of
the 9 tables are actually the same table.

Ross

SELECT DISTINCT product.product_id
FROM product,
pr_prop_str alias_table_0,
pr_prop_str alias_table_1,
pr_prop_str alias_table_2,
pr_prop_str alias_table_3,
pr_prop_str alias_table_4,
pr_prop_str alias_table_5,
pr_prop_str alias_table_6,
pr_prop_str alias_table_7,
pr_prop_str alias_table_8
WHERE product.product_id = alias_table_0.product_id
AND product.product_id = alias_table_1.product_id
AND product.product_id = alias_table_2.product_id
AND product.product_id = alias_table_3.product_id
AND product.product_id = alias_table_4.product_id
AND product.product_id = alias_table_5.product_id
AND product.product_id = alias_table_6.product_id
AND product.product_id = alias_table_7.product_id
AND product.product_id = alias_table_8.product_id
AND ( alias_table_0.pr_property_id = 147
AND alias_table_0.str = '3E362cb' )
AND ( alias_table_1.pr_property_id = 18
AND alias_table_1.str > '000999999' )
AND ( alias_table_2.pr_property_id = 18
AND alias_table_2.str < '004999999' )
AND ( alias_table_3.pr_property_id = 51
AND alias_table_3.str = '?$Bi_O?$B%&e_C~O?$Be_C?$B%&e_C~I?$Be_C?$B%)' )
AND ( alias_table_4.pr_property_id = 115
AND alias_table_4.str = '1' )
AND ( alias_table_5.pr_property_id = 68
AND alias_table_5.str = '05' )
AND ( alias_table_6.pr_property_id = 113
AND alias_table_6.str < '030001' )
AND ( alias_table_7.pr_property_id = 57
AND alias_table_7.str < '19980101' )
AND ( alias_table_8.pr_property_id = 158
AND alias_table_8.str = '1' );

On Wed, Jun 20, 2001 at 04:18:52PM +0900, Rainer Mager wrote:
> Hi,
>
> Here is a query that demonstrates the problem. Running this takes about
> 60MB until it is done at which time it is freed (I was wrong when I said
> otherwise earlier). Interestingly, the same amount of memory is used when
> doing an EXPLAIN on this query. Also it happens to return 0 rows. Please
> excuse the weird characters in the middle this is a Japanese (UTF8)
> database. Also please excuse Outlook breaking the query, it is just one long
> line.
>
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Peter Eisentraut 2001-06-20 15:48:28 Re: Notice logging.
Previous Message Josh Berkus 2001-06-20 14:54:59 Re: [SQL] log file

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2001-06-20 20:43:39 Re: The bytea datatype and JDBC
Previous Message Thalis A. Kalfigopoulos 2001-06-20 15:10:21 Re: Re: [PATCHES] [PATCH] Contrib C source for casting MONEY to INT[248] and FLOAT[48]

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2001-06-20 15:43:07 Re: use GUC for cmdline
Previous Message Thalis A. Kalfigopoulos 2001-06-20 15:10:21 Re: Re: [PATCHES] [PATCH] Contrib C source for casting MONEY to INT[248] and FLOAT[48]