Re: 7.4 vs 7.3 ( hash join issue ) - Mailing list pgsql-performance

Dennis Bjorklund wrote:
> On Wed, 22 Sep 2004, Gaetano Mendola wrote:
>
>
>>Now my question is why the 7.4 choose the hash join ?  :-(
>
>
> It looks to me that the marge join is faster because there wasn't really
> anything to merge, it resulted in 0 rows. Maybe the hash join that is
> choosen in 7.4 would have been faster had there been a couple of result
> rows (just a guess).
>
> It would be interesting to compare the plans in 7.4 with and without
> hash_join active and see what costs it estimates for a merge join compared
> to a hash join.

Here they are:

hash_join = on

                                                                                             QUERY PLAN

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Limit  (cost=10.21..10.21 rows=1 width=24) (actual time=0.885..0.885 rows=0 loops=1)
    ->  Sort  (cost=10.21..10.21 rows=1 width=24) (actual time=0.880..0.880 rows=0 loops=1)
          Sort Key: e.id_evento
          ->  Hash Join  (cost=9.02..10.21 rows=1 width=24) (actual time=0.687..0.687 rows=0 loops=1)
                Hash Cond: ("outer".id_tipo_evento = "inner".id_tipo_evento)
                ->  Seq Scan on lookup_tipo_evento le  (cost=0.00..1.16 rows=16 width=32) (actual time=0.017..0.038
rows=16loops=1) 
                ->  Hash  (cost=9.02..9.02 rows=1 width=16) (actual time=0.212..0.212 rows=0 loops=1)
                      ->  Index Scan using t_evento_id_pratica_key on t_evento e  (cost=0.00..9.02 rows=1 width=16)
(actualtime=0.208..0.208 rows=0 loops=1) 
                            Index Cond: (id_pratica = 5)
                            Filter: (((id_tipo_evento)::text = '5'::text) OR ((id_tipo_evento)::text = '6'::text) OR
((id_tipo_evento)::text= '7'::text) OR ((id_tipo_evento)::text = '8'::text)) 
  Total runtime: 1.244 ms
(11 rows)

hash_join = off
                                                                                             QUERY PLAN

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Limit  (cost=10.28..10.28 rows=1 width=24) (actual time=0.429..0.429 rows=0 loops=1)
    ->  Sort  (cost=10.28..10.28 rows=1 width=24) (actual time=0.425..0.425 rows=0 loops=1)
          Sort Key: e.id_evento
          ->  Merge Join  (cost=10.25..10.27 rows=1 width=24) (actual time=0.218..0.218 rows=0 loops=1)
                Merge Cond: ("outer".id_tipo_evento = "inner".id_tipo_evento)
                ->  Sort  (cost=9.02..9.02 rows=1 width=16) (actual time=0.214..0.214 rows=0 loops=1)
                      Sort Key: e.id_tipo_evento
                      ->  Index Scan using t_evento_id_pratica_key on t_evento e  (cost=0.00..9.02 rows=1 width=16)
(actualtime=0.110..0.110 rows=0 loops=1) 
                            Index Cond: (id_pratica = 5)
                            Filter: (((id_tipo_evento)::text = '5'::text) OR ((id_tipo_evento)::text = '6'::text) OR
((id_tipo_evento)::text= '7'::text) OR ((id_tipo_evento)::text = '8'::text)) 
                ->  Sort  (cost=1.22..1.23 rows=16 width=32) (never executed)
                      Sort Key: le.id_tipo_evento
                      ->  Seq Scan on lookup_tipo_evento le  (cost=0.00..1.16 rows=16 width=32) (never executed)
  Total runtime: 0.721 ms
(14 rows)





Regards
Gaetano Mendola