Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2

Em 06-11-2012 19:11, Merlin Moncure escreveu:
> On Tue, Nov 6, 2012 at 1:45 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Rodrigo Rosenfeld Rosas<rr(dot)rosas(at)gmail(dot)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...

This was a great guess! Congrats, Merlin:

PG 9.1 (port 5433):

time psql -p 5433 -f slow-explain-only.sql db_name > /dev/null

real 0m0.284s
user 0m0.068s
sys 0m0.012s

time psql -p 5432 -f slow-explain-only.sql db_name > /dev/null

real 2m10.409s
user 0m0.056s
sys 0m0.016s

time psql -p 5433 -f fast-explain-only.sql db_name > /dev/null

real 0m0.264s
user 0m0.064s
sys 0m0.020s

time psql -p 5432 -f fast-explain-only.sql db_name > /dev/null

real 12m25.084s
user 0m0.052s
sys 0m0.020s

This is great news because it makes it easier for me to provide a
test-case since the results were the same in my test database (which is
mostly empty):

time psql -p 5432 -f fast-explain-only.sql db_test > /dev/null

real 6m0.414s
user 0m0.064s
sys 0m0.024s

I'm in Brazil which is 3 hours behind NY, where my client is. Later when
they start their journey I'll ask them if I can send our plain database
schema to make it even easier. Otherwise, if they prefer me to create
another database schema or to drop the unrelated tables first I'll do
that. Maybe they could be afraid of SQL injection attacks although I
believe we're currently free of errors of this nature in our applications.

Thank you so much for narrowing down the real problem with 9.2.

After this regression is fixed in 9.2 I'd like to know if it would be
possible to optimize the planner so that slow.sql could perform as well
as fast.sql. I believe the unique index on (transaction_id, type_id)
helps slow.sql to perform better but if the planner could be smart
enough to understand that slow.sql and fast.sql are equivalents I'd
prefer to use slow.sql instead of fast.sql as it reads better and it is
easier to maintain and write tests for and reduces our database log files.

Cheers,
Rodrigo.