SQL statement over 500% slower with 9.2 compared with 9.1

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

Hello

We have a SQL statement that with 9.1 takes ca 4000ms to finnish and
with 9.2 over 22000ms.

The explain analyze information is here:

With 9.1.:
http://explain.depesz.com/s/5ou

With 9.2
http://explain.depesz.com/s/d4vU

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
                                       )
                       )
;


The tables information:

# SELECT count(*) from filmparticipation;
  count
- ----------
 10835351
(1 row)

# SELECT pg_size_pretty(pg_table_size('filmparticipation'));
 pg_size_pretty
- ----------------
 540 MB
(1 row)

# SELECT count(*) from person;
  count
- ---------
 1709384
(1 row)

# SELECT pg_size_pretty(pg_table_size('person'));
 pg_size_pretty
- ----------------
 85 MB
(1 row)


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?

Some additional information:

* VACUUM ANALYZE has been run in both databases.
* Both databases are running on servers running RHEL6.3.
* The relevant parameters changed from the default configuration are:

9.1:
- ----

 checkpoint_segments         | 128
 client_encoding             | UTF8
 effective_cache_size        | 28892MB
 maintenance_work_mem        | 256MB
 max_connections             | 400
 max_stack_depth             | 4MB
 random_page_cost            | 2
 server_encoding             | UTF8
 shared_buffers              | 8026MB
 ssl                         | on
 ssl_renegotiation_limit     | 0
 wal_buffers                 | 16MB
 wal_level                   | archive
 wal_sync_method             | fdatasync
 work_mem                    | 16MB


9.2:
- ----

 checkpoint_segments         | 128
 client_encoding             | UTF8
 effective_cache_size        | 28892MB
 maintenance_work_mem        | 256MB
 max_connections             | 400
 max_stack_depth             | 4MB
 random_page_cost            | 2
 server_encoding             | UTF8
 shared_buffers              | 8026MB
 ssl                         | on
 ssl_renegotiation_limit     | 0
 wal_buffers                 | 16MB
 wal_level                   | archive
 wal_sync_method             | fdatasync
 work_mem                    | 16MB


Any ideas on why this is happening and how to fix it?

Thanks in advance for your time.
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)

iEYEARECAAYFAlIbSyoACgkQBhuKQurGihTOYwCfWC/ptAuMQ1pxFcplq9bHfBi3
uekAnj+nll/Z2Lr8kFgPAB6Fx0Kop4/0
=3TPA
-----END PGP SIGNATURE-----