[PERFORM] Query with no result set, really really slow adding ORBDER BY / LIMIT clause

QUERY 1 FAST:
--------------------------------

SELECT  fase.id
FROM            tipofase
JOIN       fase
ON         (fase.tipofase = tipofase.id)
WHERE   tipofase.agendafrontoffice = true

EXPLAIN ANALYZE:

Nested Loop  (cost=0.43..790.19 rows=14462 width=4) (actual time=0.079..0.079 rows=0 loops=1)

  ->  Seq Scan on tipofase  (cost=0.00..3.02 rows=1 width=4) (actual time=0.077..0.077 rows=0 loops=1)
        Filter: agendafrontoffice
        Rows Removed by Filter: 102
  ->  Index Only Scan using fase_test_prova_4 on fase  (cost=0.43..595.59 rows=19158 width=8) (never executed)
        Index Cond: (tipofase = tipofase.id)
        Heap Fetches: 0
Planning time: 0.669 ms
Execution time: 0.141 ms

---

It's perfect because it starts from tipofase, where there are no agendafrontoffice = true

fase_test_prova_4 is a btree index ON (fase.tipofase, fase.id)
fase.id is PRIMARY key on fase, 
tipofase.id is PRIMARY key on tipofase, 
fase.tipofase is FK on tipofase.id
and tipofase.agendafrontoffice is a boolean. 

QUERY 2 SLOW(WITH limit and order by):
--------------------------------


SELECT  fase.id
FROM            tipofase
JOIN       fase
ON         (fase.tipofase = tipofase.id)
WHERE   tipofase.agendafrontoffice = true
ORDER BY        fase.id DESC limit 10 offset 0

Limit  (cost=0.43..149.66 rows=10 width=4) (actual time=173853.131..173853.131 rows=0 loops=1)
  ->  Nested Loop  (cost=0.43..215814.25 rows=14462 width=4) (actual time=173853.130..173853.130 rows=0 loops=1)
        Join Filter: (fase.tipofase = tipofase.id)
        ->  Index Scan Backward using test_prova_2 on fase  (cost=0.43..193684.04 rows=1475146 width=8) (actual time=1.336..173128.418 rows=1475146 loops=1)
        ->  Materialize  (cost=0.00..3.02 rows=1 width=4) (actual time=0.000..0.000 rows=0 loops=1475146)
              ->  Seq Scan on tipofase  (cost=0.00..3.02 rows=1 width=4) (actual time=0.000..0.000 rows=0 loops=1)
                    Filter: agendafrontoffice
                    Rows Removed by Filter: 102
Planning time: 0.685 ms
Execution time: 173853.221 ms

Really really slow..... looks like the planner is not doing a good job.
PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit


I also run VACUUM  AND VACUUM ANALYZE on both table
I tried to play with the 
"alter table tipofase alter column agendafrontoffice set statistics 2"
but nothing.

Thanks in advance Marco