Re: Select retrieval slowdown after db drop/reload. Suggestions?

From: Naz Gassiep <naz(at)mira(dot)net>
To: Andrew Edson <cheighlund(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Select retrieval slowdown after db drop/reload. Suggestions?
Date: 2007-03-01 00:38:52
Message-ID: 45E6209C.9070206@mira.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
You have to run ANALYZE; on your db after a drop/reload to recollect
the stats. In the rest db, jus run ANALYZE; and then see how fast it
is. I'd guess that this is your issue.<br>
Regards,<br>
- Naz.<br>
<br>
Andrew Edson wrote:
<blockquote cite="mid984673(dot)72139(dot)qm(at)web34205(dot)mail(dot)mud(dot)yahoo(dot)com"
type="cite">
<div>I have a select statement, used in a Perl program, which is
supposed to find all records related to those in one table which have a
delete_dt field value of&nbsp;four years or older.&nbsp; </div>
<div>&nbsp;</div>
<div>This is the select statement:<br>
SELECT t2.dist_id, t1.clnt_seq, t2.cntrct_seq, t2.cntrct_id,
t3.aunit_seq, t1.person_seq, t1.addr_seq, t3.addr_seq, t4.frst_nm || '
' || t4.lst_nm AS name, t5.addr_1, t6.acntdel_dt FROM t1, t2, t3, t4,
t5, t6 WHERE t1.clnt_seq = t2.clnt_seq AND t2.cntrct_seq =
t3.cntrct_seq AND t3.aunit_seq = t6.aunit_seq AND t1.person_seq =
t4.person_seq AND t3.addr_seq = t5.addr_seq AND t1.active_flg =0 AND
t2.active_flg =0 AND t3.active_flg = 0 AND t6.acntdel_dt &lt; now() -
'4 years'::interval order by t2.cntrct_id asc;</div>
<div>&nbsp;</div>
<div>I'm working on a test box at the moment; the db I am using was
made by dumping the production db and copying it over to the test box
to be loaded into a newly-created db there.&nbsp; It took a while for me to
get the original Perl program working, as I don't really understand
Perl, but after I did so, I dropped the db and reloaded it again off of
the original files, so I could try another test run and pay attention
to what's happening.</div>
<div>&nbsp;</div>
<div>On the original load of the test db, the query above had a run
time of roughly 3, 3.5 minutes before giving results.&nbsp; Considering the
size of the db it's searching through, I feel that's fairly reasonable,
especially since that's about what the production db does on the same
query.&nbsp; Now, after the drop/recreate, the test db is taking somewhat
longer to give back its results; just shy of 7 minutes, if I've done
the math correctly.&nbsp; (Timing results - Time: 417531.436 ms)</div>
<div>&nbsp;</div>
<div>I'm the only person working on this particular box at this
point.&nbsp; This problem did not start until I reloaded the db from the
original files.&nbsp; Obviously, I managed to miss something in the
drop/reload process, but I have no clue what.&nbsp; I'm running a vacuum
full analyze at the moment; if anyone has any other suggestions as to
what I could do to solve this (admittedly minor) problem, I would be
grateful to hear them.</div>
<div>&nbsp;</div>
<div>Thank you for your consideration.</div>
<div>&nbsp;</div>
<p> </p>
<hr size="1">No need to miss a message. <a
href="http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail">Get
email on-the-go </a><br>
with Yahoo! Mail for Mobile. <a
href="http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail">Get
started.</a>
</blockquote>
</body>
</html>

Attachment Content-Type Size
unknown_filename text/html 3.1 KB

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paul Lambert 2007-03-01 00:44:19 PG periodic Error on W2K
Previous Message Bill Moran 2007-03-01 00:24:35 Re: why can't I increase shared buffers to higher value?