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

From Merlin Moncure
Subject Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
Date
Msg-id CAHyXU0xRk0LCj6NYuTAUaWN2FDAWj+jHgH2niDAGtb1w4QT83w@mail.gmail.com
Whole thread Raw
In response to Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
List pgsql-performance
On Tue, Nov 6, 2012 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> writes:
>> Em 06-11-2012 17:24, Tom Lane escreveu:
>>> 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.
>
>> I'd love to, but I'm afraid I won't have time to do this any time soon.
>> Maybe on Sunday. I'll see if I can get a script to generate the database
>> on Sunday and hope for it to replicate the issue.
>
>> Would you mind if I coded it using Ruby? (can you run Ruby code in your
>> computer?) I mean, for filling with some sample data.
>
> No objection.

hm, wouldn't timing the time to generate a raw EXPLAIN (that is,
without ANALYZE) give a rough estimate of planning time?   better to
rule it out before OP goes to the trouble...

merlin


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: Tom Lane
Date:
Subject: Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2