Skip site navigation (1) Skip section navigation (2)

Re: Analyze on temp table taking very long

From: "Mahadevan, Mridula" <Mridula(dot)Mahadevan(at)ironmountain(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Analyze on temp table taking very long
Date: 2011-03-25 17:32:42
Message-ID: 300035A46398FC4D8251A684DE0416737D3B8316@mvmexp01.tpt.imtn.com (view raw or flat)
Thread:
Lists: pgsql-performance
Thanks for the tip. I'll also check in the lock, it's a customer setup and we don't get access to the box very frequently. 
Also
The code was something like this. 

loop 
	inserting data into the tmptbl
	analyze tmptbl
end loop

if I replace this with 

loop 
	inserting data into the tmptbl
end loop
analyze


It goes through fine. 

-mridula



-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: Tuesday, March 22, 2011 3:57 PM
To: Mahadevan, Mridula
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Analyze on temp table taking very long

"Mahadevan, Mridula" <Mridula(dot)Mahadevan(at)ironmountain(dot)com> writes:
> This has been running fine for a while on multiple setups, large and small volumes. The setups all have the same hardware configuration.

> On one particular setup with about 200k records and this analyze runs for 45min and then times out(statement timeout is set to 45 min). typically this takes a few seconds at best. But when I move the analyze outside the loop everything runs fine.

Is it actually *running*, as in doing something, or is it just blocked?
I can't immediately think of any reason for some other process to have
a lock on a temp table that belongs to your process; but it seems
unlikely that ANALYZE would randomly take much longer than expected
unless something was preventing it from making progress.

Look into pg_locks and/or watch the backend with strace next time this
happens.

			regards, tom lane

-- 
Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. 


In response to

pgsql-performance by date

Next:From: Scott CareyDate: 2011-03-25 17:55:08
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
Previous:From: Maciek SakrejdaDate: 2011-03-25 16:49:31
Subject: Re: Why Index is not used

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group