Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 61702632A55 for ; Mon, 4 Jan 2010 16:40:12 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 98358-01 for ; Mon, 4 Jan 2010 20:39:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gpdnet.co.uk (gpdnet.plus.com [212.56.100.243]) by mail.postgresql.org (Postfix) with SMTP id C3AFC632460 for ; Mon, 4 Jan 2010 16:40:00 -0400 (AST) Received: (qmail 25990 invoked by uid 453); 4 Jan 2010 10:13:31 -0000 Received: from pc-00002.gpdnet.co.uk (HELO [192.168.1.2]) (192.168.1.2) by gpdnet.co.uk (qpsmtpd/0.40) with ESMTP; Mon, 04 Jan 2010 10:13:31 +0000 Message-ID: <4B425222.7070905@gpdnet.co.uk> Date: Mon, 04 Jan 2010 20:40:02 +0000 From: Gary Doades User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Madison Kelly CC: pgsql-performance@postgresql.org Subject: Re: DB is slow until DB is reloaded References: <4B423D22.7040803@alteeve.com> <4B424215.70605@pinpointresearch.com> <4B424FF6.40207@alteeve.com> In-Reply-To: <4B424FF6.40207@alteeve.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.448 tagged_above=-10 required=5 tests=BAYES_20=-0.74, FH_DATE_PAST_20XX=3.188 X-Spam-Level: ** X-Archive-Number: 201001/12 X-Sequence-Number: 36892 On 04/01/2010 8:30 PM, Madison Kelly wrote: > Steve Crawford wrote: >> Madison Kelly wrote: >>> Hi all, >>> >>> I've got a fairly small DB... >>> >>> It slows down over time and I can't seem to find a way to get the >>> performance to return without doing a dump and reload of the >>> database... >> >> Some questions: >> >> Is autovacuum running? This is the most likely suspect. If not, >> things will bloat and you won't be getting appropriate "analyze" >> runs. Speaking of which, what happens if you just run "analyze"? >> >> And as long as you are dumping and reloading anyway, how about >> version upgrading for bug reduction, performance improvement, and >> cool new features. >> >> Cheers, >> Steve >> > > Yup, I even tried manually running 'VACUUM FULL' and it didn't help. > As for upgrading; > VACUUM FULL is not the same as VACUUM ANALYZE FULL. You shouldn't need the FULL option amyway. > a) I am trying to find a way around the dump/reload. I am doing it as > a "last resort" only. > b) I want to keep the version in CentOS' repo. > > I'd not tried simply updating the stats via ANALYZE... I'll keep an > eye on performance and if it starts to slip again, I will run ANALYZE > and see if that helps. If there is a way to run ANALYZE against a > query that I am missing, please let me know. > From your queries it definitely looks like its your stats that are the problem. When the stats get well out of date the planner is choosing a hash join because it thinks thousands of rows are involved where as only a few are actually involved. Thats why, with better stats, the second query is using a loop join over very few rows and running much quicker. Therefore it's ANALYZE you need to run as well as regular VACUUMing. There should be no need to VACUUM FULL at all as long as you VACUUM and ANALYZE regularly. Once a day may be enough, but you don't say how long it takes your database to become "slow". You can VACUUM either the whole database (often easiest) or individual tables if you know in more detail what the problem is and that only certain tables need it. Setting up autovacuum may well be sufficient. Cheers, Gary. > Madi >