Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2 - Mailing list pgsql-performance

From Tom Lane
Subject Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
Date
Msg-id 17866.1352229874@sss.pgh.pa.us
Whole thread Raw
In response to Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2  (Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>)
Responses Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
List pgsql-performance
Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> writes:
> Em 06-11-2012 16:42, Merlin Moncure escreveu:
>> Hm -- looking at your 'slow' 9.2 query, it is reporting that the query
>> took 3 seconds  (reported times are in milliseconds).  How are you
>> timing the data?  What happens when you run explain analyze
>> <your_query>  from psql (as in, how long does it take)?

> The time I reported in the tables of my first message were the time
> reported by pgAdmin3 (compiled from source).

> But I get similar time when I run like this:

> time psql -p 5432 -f slow.sql db_name > slow-9.2-again.explain

> real    1m56.353s
> user    0m0.068s
> sys     0m0.020s

> slow-9.2-again.explain: http://explain.depesz.com/s/zF1

But that again shows only five seconds runtime.  If you repeat the query
several dozen times in a row, run the same way each time, do you get
consistent timings?

Can you put together a self-contained test case to duplicate these
results?  I'm prepared to believe there's some sort of planner
regression involved here, but we'll never find it without a test case.

            regards, tom lane


pgsql-performance by date:

Previous
From: "Gunnar \"Nick\" Bluth"
Date:
Subject: Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
Next
From: Rodrigo Rosenfeld Rosas
Date:
Subject: Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2