Ahh ok no había probando nunca con un IS NULL, gracias por la corrección!!! El 16/12/2014 08:20, "Martín Marqués" <mar...@2ndquadrant.com> escribió:
> El 16/12/14 a las 10:07, Hellmuth Vargas escribió: > > Hola lista > > > > Martín disculpe la ignorancia, pero tengo entendido que si se coloca una > > condición filtró en el where de la tabla B, el left outer se convierte > en > > inner join y se pierde el efecto. Por favor corrijame si me equivoco > > Te corrijo! ;) > > Prueba con un EXPLAIN ANALYZE para ver como PostgreSQL planifica la > consulta. > > explain analyze select * from personas where codigo NOT IN (SELECT > persona FROM usuarios); > QUERY PLAN > > > ------------------------------------------------------------------------------------------------------------------------ > Seq Scan on personas (cost=3084.72..6036.51 rows=62552 width=46) > (actual time=111.600..162.448 rows=15 loops=1) > Filter: (NOT (hashed SubPlan 1)) > Rows Removed by Filter: 125088 > SubPlan 1 > -> Seq Scan on usuarios (cost=0.00..2714.98 rows=147898 width=4) > (actual time=0.011..31.877 rows=147898 loops=1) > Total runtime: 162.520 ms > > > explain analyze select * from personas p LEFT OUTER JOIN usuarios u ON > (p.codigo=u.persona) where u.persona IS NULL; > QUERY PLAN > > > ------------------------------------------------------------------------------------------------------------------------------- > Hash Anti Join (cost=5719.70..18174.42 rows=13388 width=83) (actual > time=74.550..195.594 rows=15 loops=1) > Hash Cond: (p.codigo = u.persona) > -> Seq Scan on personas p (cost=0.00..2639.03 rows=125103 width=46) > (actual time=0.004..19.270 rows=125103 loops=1) > -> Hash (cost=2714.98..2714.98 rows=147898 width=37) (actual > time=70.090..70.090 rows=147898 loops=1) > Buckets: 16384 Batches: 2 Memory Usage: 4749kB > -> Seq Scan on usuarios u (cost=0.00..2714.98 rows=147898 > width=37) (actual time=0.003..23.560 rows=147898 loops=1) > Total runtime: 195.660 ms > > En este caso, anduvo más rápido con el NOT IN (), pero eso depende mucho > de cuantos datos se esten filtrando, cuantos datos totales haya en cada > tabla, etc. > > 200k no es una gran tabla, IMO. > > Saludos, > > -- > Martín Marqués http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >