Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id F0FEF2E003B
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 12 Feb 2008 04:32:34 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 84396-09 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 12 Feb 2008 04:32:31 -0400 (AST)
Received: from fk-out-0910.google.com (fk-out-0910.google.com
 [209.85.128.184])
	by postgresql.org (Postfix) with ESMTP id B6B2F2E0321
	for <pgsql-performance@postgresql.org>;
	Tue, 12 Feb 2008 04:32:30 -0400 (AST)
Received: by fk-out-0910.google.com with SMTP id b27so5652498fka.3
	for <pgsql-performance@postgresql.org>;
	Tue, 12 Feb 2008 00:32:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=rbydanVynEpQtiHNTYSU/fegXIsqYcm0nh7linfZYn0=;
	b=TywtMtg2YzW52C/gstdnVSUcVzdtBEtQDdJRVirIwvj9xl+Luz7jIaeEsvHCSarsDZNsG5W+t3nMS6R/EmuLuA3kA+vo6oLgjH4nSsDVqoBHKZE3a9wIXj9BOjSgSgW5zU79mzh/fdjRmmlO9ym2BvqyEoB39V0Hu18O1UTBxuM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=iNk1qxqG8o6Fc+N6BXGzpniXVKIwwAf7iSDoUQfr2V7u/lWw34lv6bgZjkldsYdmE9izza/PkcUGuC1s5Mbiybabixbm80/am1QRSxe7eRyYq94WweOnhbkU6jnPG0GwRwheb+v+5fFfMZUwHUYhPok6QBUI2HpIPKVwtfL6324=
Received: by 10.78.155.4 with SMTP id c4mr1760563hue.79.1202805149373;
	Tue, 12 Feb 2008 00:32:29 -0800 (PST)
Received: by 10.78.146.1 with HTTP; Tue, 12 Feb 2008 00:32:29 -0800 (PST)
Message-ID: <3caa866c0802120032r7b7eb672s98d38f1351622424@mail.gmail.com>
Date: Tue, 12 Feb 2008 13:32:29 +0500
From: "Linux Guru" <linux.binary@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: Update with Subquery Performance
Cc: pgsql-performance@postgresql.org
In-Reply-To: <2982.1202749162@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_35926_14549714.1202805149372"
References: <3caa866c0802110306rcb5e72dyd264ff330c61f8ae@mail.gmail.com>
	<2982.1202749162@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200802/112
X-Sequence-Number: 28654

------=_Part_35926_14549714.1202805149372
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Analyzing did not help, here is the out of EXPLAIN ANALYZE of update query

"Seq Scan on dummy  (cost=0.00..56739774.24 rows=23441 width=275) (actual
time=18.927..577929.014 rows=22712 loops=1)"
"  SubPlan"
"    ->  Aggregate  (cost=2420.41..2420.43 rows=1 width=19) (actual time=
25.423..25.425 rows=1 loops=22712)"
"          ->  Seq Scan on dummy "temp"  (cost=0.00..2416.01 rows=586
width=19) (actual time=0.049..17.834 rows=2414 loops=22712)"
"                Filter: ((product)::text = ($0)::text)"
"Total runtime: 578968.885 ms"


On Feb 11, 2008 9:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Linux Guru" <linux.binary@gmail.com> writes:
> > We have a large datawarehouse stored in postgres and temp tables are
> created
> > based on user query. The process of temp table creation involves
> selecting
> > data from main fact table, this includes several select and update
> > statements and one of the following update statement is having
> performance
> > issues.
>
> Try ANALYZEing the temp table before the step that's too slow.
>
> If that doesn't help, let's see EXPLAIN ANALYZE (not just EXPLAIN)
> output.
>
>                        regards, tom lane
>

------=_Part_35926_14549714.1202805149372
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Analyzing did not help, here is the out of EXPLAIN ANALYZE of update query<br><br>&quot;Seq Scan on dummy&nbsp; (cost=0.00..56739774.24 rows=23441 width=275) (actual time=18.927..577929.014 rows=22712 loops=1)&quot;<br>&quot;&nbsp; SubPlan&quot;<br>
&quot;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; Aggregate&nbsp; (cost=2420.41..2420.43 rows=1 width=19) (actual time=25.423..25.425 rows=1 loops=22712)&quot;<br>&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; Seq Scan on dummy &quot;temp&quot;&nbsp; (cost=0.00..2416.01 rows=586 width=19) (actual time=0.049..17.834 rows=2414 loops=22712)&quot;<br>
&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filter: ((product)::text = ($0)::text)&quot;<br>&quot;Total runtime: 578968.885 ms&quot;<br><br><br><div class="gmail_quote">On Feb 11, 2008 9:59 PM, Tom Lane &lt;<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">&quot;Linux Guru&quot; &lt;<a href="mailto:linux.binary@gmail.com">linux.binary@gmail.com</a>&gt; writes:<br>
&gt; We have a large datawarehouse stored in postgres and temp tables are created<br>&gt; based on user query. The process of temp table creation involves selecting<br>&gt; data from main fact table, this includes several select and update<br>
&gt; statements and one of the following update statement is having performance<br>&gt; issues.<br><br></div>Try ANALYZEing the temp table before the step that&#39;s too slow.<br><br>If that doesn&#39;t help, let&#39;s see EXPLAIN ANALYZE (not just EXPLAIN)<br>
output.<br><br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;regards, tom lane<br></blockquote></div><br>

------=_Part_35926_14549714.1202805149372--