Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 6AF0A6328F3 for ; Tue, 16 Feb 2010 06:26:34 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 88000-03 for ; Tue, 16 Feb 2010 10:26:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.17]) by mail.postgresql.org (Postfix) with ESMTP id F1AF8632822 for ; Tue, 16 Feb 2010 06:26:22 -0400 (AST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1909.orange.fr (SMTP Server) with ESMTP id 1509B1C005AA for ; Tue, 16 Feb 2010 11:26:20 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1909.orange.fr (SMTP Server) with ESMTP id E16A91C00680 for ; Tue, 16 Feb 2010 11:26:19 +0100 (CET) Received: from [192.168.10.15] (ARennes-257-1-110-118.w86-210.abo.wanadoo.fr [86.210.21.118]) by mwinf1909.orange.fr (SMTP Server) with ESMTP id 7F2511C005AA for ; Tue, 16 Feb 2010 11:26:19 +0100 (CET) X-ME-UUID: 20100216102619520.7F2511C005AA@mwinf1909.orange.fr Message-ID: <4B7A72CA.2030305@boozter.com> Date: Tue, 16 Feb 2010 11:26:18 +0100 From: lionel duboeuf User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Almost infinite query -> Different Query Plan when changing where clause value References: <4B790387020000250002F2CF@gw.wicourts.gov> In-Reply-To: <4B790387020000250002F2CF@gw.wicourts.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/250 X-Sequence-Number: 37671 Here is my log analysis: Due to a database recovery task it appears that: I stopped postgresql I started postgresql (and as default autovacuum daemon) I restored the databases (need to restore 4 databases) It seems that after database 1 have been restored, autovacumm started on it and has been stopped while restoring database 2. @see log as attached Here is backup/restore commands i use: /usr/bin/pg_dump -i -h localhost -U postgres -F c -b -f ... x 4 times sudo -u postgres pg_restore -d 'database1' x 4 times Does this kind of error can lead to the query problem ? If so, what would you suggest me to do to avoid the problem again ?. Thanks Lionel Kevin Grittner a écrit : > lionel duboeuf wrote: > >> Kevin Grittner a écrit : >> > > >>> I just reread your original email, and I'm not sure I understand >>> what you meant regarding VACUUM ANALYZE. If you run that right >>> beforehand, do you still get the slow plan for user 10? >>> > > >> I confirm by executing manual "VACUUM ANALYZE" that the problem is >> solved. But what i don't understand is that i would expect >> autovacuum to do the job. >> > > I think this is the crux of the issue. Boosting the > default_statistics_target or the statistics target for specific > columns might help, reducing autovacuum_analyze_scale_factor might > help, but I can't help wondering whether you inserted a large number > of rows for user 10 and then ran the query to select user 10 before > autovacuum had time to complete. Does that seem possible? > > -Kevin > >