Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!! - Mailing list pgsql-performance

From Dave Dutcher
Subject Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
Date
Msg-id 01ba01c7fc58$cb346a40$cb00a8c0@tridecap.com
Whole thread Raw
In response to Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!  (smiley2211 <smiley2211@yahoo.com>)
List pgsql-performance
>From: smiley2211
>Subject: Re: [PERFORM] Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
>
>->  Seq Scan on encounters_questions_answers eqa
>(cost=100000000.00..100007608.66 rows=464766 width=8) (actual
>time=0.003..735.934 rows=464766 loop
>s=7430)

It looks like enable_seqscan is set to false.  For some reason that might
have worked on 7.4, but I would try turning that back on for 8.1.
Sequential scans aren't always bad, sometimes they are faster than index
scans.  I would first try running the system with all the enable_* settings
on.

If you can't turn on logging its going to be very hard to track down the
problem.  The easiest way to track down a problem normally is to set
log_min_duration to something like 2000ms.  Then Postgres will log all slow
queries.  Then you can run EXPLAIN ANALYZE on the slow queries to find the
problem.

I think Carlos had a good idea when he asked about the encoding on the new
server vs the old.  Does your application use the like keyword to compare
text fields?  If so, you might need to create indexes which use the
text_pattern_ops operator classes.  With unicode postgres cannot use an
index scan for a query like SELECT * FROM foo WHERE name LIKE 'Bob%' unless
there is an index like CREATE INDEX name_index ON foo (name
text_pattern_ops).  However if you are not using like queries, then this is
not your problem.

More on operator classes:
http://www.postgresql.org/docs/8.1/interactive/indexes-opclass.html

Dave


pgsql-performance by date:

Previous
From: Jeff Harris
Date:
Subject: Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
Next
From: Csaba Nagy
Date:
Subject: Re: Searching for the cause of a bad plan