Re: Query slow after analyse on postgresql 8.2 - Mailing list pgsql-performance

From Kaufhold, Christian (LFD)
Subject Re: Query slow after analyse on postgresql 8.2
Date
Msg-id 0694BCCA1B37BE4B8FEB01807799BD540142B481@BLFD_2.lfd.bayern.de
Whole thread Raw
In response to Query slow after analyse on postgresql 8.2  ("Kaufhold, Christian (LFD)" <Christian.Kaufhold@blfd.bayern.de>)
List pgsql-performance
Thanks Tom,

alter table boden.massnahmeobjekt alter column aktennummer set statistics 1000;

fixed it.

Regards
Christian


-----Ursprüngliche Nachricht-----
Von: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] Im Auftrag von Tom Lane
Gesendet: Donnerstag, 17. Juni 2010 16:59
An: Kaufhold, Christian (LFD)
Cc: pgsql-performance@postgresql.org
Betreff: Re: [PERFORM] Query slow after analyse on postgresql 8.2

"Kaufhold, Christian (LFD)" <Christian.Kaufhold@blfd.bayern.de> writes:
> I have the following query that I run agains postgresql 8.2:
> ...
> But when I run analyse the same query runs for hours.

Seems like the core of the problem is here:

>                                                               ->  Seq
> Scan on massnahmeobjekt m  (cost=0.00..3271.88 rows=1 width=94)
> (actual
> time=0.387..577.771 rows=3694 loops=1)
> Filter: ((aktennummer)::text ~* 'M\\-2009\\-1'::text)

If that rowcount estimate weren't off by three orders of magnitude you probably would be getting a more appropriate
plan. The first thing you could try is increasing the statistics target for aktennummer.  Also, if you're running in a
non-Clocale and this is 8.2.5 or older, try a more recent 8.2.x.  Updating to 8.3 or 8.4 might help even more. 

            regards, tom lane

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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query slow after analyse on postgresql 8.2
Next
From: Josh Berkus
Date:
Subject: Re: PostgreSQL as a local in-memory cache