From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ronaldo Maia <romaia@async.com.br>
cc: pgsql-performance@postgresql.org
Subject: Re: Possible regression (slow query on 9.2/9.3 when compared to 9.1)
In-reply-to: 
 <CAJMy52gS=RgMxk6FBjyQMeLL2vDLT5Jvhv8cw-X=CV44jZNaYQ@mail.gmail.com>
References: 
 <CAJMy52gS=RgMxk6FBjyQMeLL2vDLT5Jvhv8cw-X=CV44jZNaYQ@mail.gmail.com>
Comments: In-reply-to Ronaldo Maia <romaia@async.com.br>
 message dated "Thu, 26 Dec 2013 17:49:29 -0200"
Date: Sun, 29 Dec 2013 17:32:20 -0500
Message-ID: <30316.1388356340@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Ronaldo Maia <romaia@async.com.br> writes:
> Recently I have tried to upgrade our postgres instalation from 9.1 to 9.3,
> but one query in particular got extremelly slow.

FWIW, this test case doesn't reproduce any problem for me --- I get
identical plans and indistinguishable timings (about 450ms on my machine)
from 9.1 and 9.3 branch tips.  This is with all-default settings and
a VACUUM ANALYZE after loading the data.  I had to guess at the definition
of stoq_normalize_string(), too, so I used

create function stoq_normalize_string(text) returns text language sql
  strict immutable as 'select unaccent($1)';

I speculate that you forgot to analyze the data after loading, or there's
some performance-relevant setting that you didn't carry forward from the
9.1 database.

			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