Re: SQL statement over 500% slower with 9.2 compared with 9.1

From: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: SQL statement over 500% slower with 9.2 compared with 9.1
Date: 2013-08-27 09:19:27
Message-ID: 521C6F1F.5070901@usit.uio.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/26/2013 02:33 PM, Rafael Martinez wrote:
[............]
> The SQL statement is:
>
> SELECT firstname || ' ' || lastname AS Name FROM Person R WHERE
> R.gender like 'F' AND 19 < (SELECT COUNT(DISTINCT filmId) FROM
> FilmParticipation F WHERE F.partType = 'director' AND F.personId =
> R.personId ) AND NOT EXISTS ( SELECT * FROM
> FilmParticipation D WHERE D.partType = 'director' AND D.personId
> = R.personId AND NOT EXISTS ( SELECT * FROM FilmParticipation
> C WHERE C.partType = 'cast' AND C.filmId = D.filmId AND
> C.personId = D.personId ) ) ;
>
>
[.............]
>
> We can see that the query plan is very different between versions
> and that 9.2 is really wrong with the number of rows involved. Why
> is 9.2 taking so wrong about the number of rows involved in some
> parts of the plan?
>

Hei

More information:

If we turn off enable_indexscan the runtime gets more similar to the
one we get with 9.1, we are down to 4200ms.

The query plan with this configuration is here:
http://explain.depesz.com/s/jVR

The question remains the same, why is 9.2 using such a different and
bad plan compared to 9.1, when the data and the configuration are the
same?

regards,
- --
Rafael Martinez Guerrero
Center for Information Technology
University of Oslo, Norway

PGP Public Key: http://folk.uio.no/rafael/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlIcbx8ACgkQBhuKQurGihReJgCcCiEfGQ0rZHcazlN3Ihb2PeCn
jOsAnjkh1M0j4r1DQJ4Xb1djZ+y4mji3
=Td8b
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2013-08-27 13:23:07 Re: Cpu usage 100% on slave. s_lock problem.
Previous Message Дмитрий Дегтярёв 2013-08-27 07:57:20 Cpu usage 100% on slave. s_lock problem.