sorry...i made a mistake...my tables are unlogged and in the last test these was wiped... :(
when i create the tables again (with all record) the result is: pba=# \i tablas.sql DROP TABLE SELECT 120130 CREATE INDEX CREATE INDEX CREATE INDEX DROP TABLE SELECT 91932 CREATE INDEX CREATE INDEX pba=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT idprodxintegrar FROM _gc_tb a LEFT join _gc_cat b on ( b.arama <@ a.arama and a.arama <@ b.arama ) ; Terminado (killed) :( 2016-03-04 15:30 GMT-06:00 David G. Johnston <david.g.johns...@gmail.com>: > On Fri, Mar 4, 2016 at 2:16 PM, Felipe de Jesús Molina Bravo < > fjmolinabr...@gmail.com> wrote: > >> the output is: >> >> pba=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT idprodxintegrar FROM >> _gc_tb a LEFT join _gc_cat b on ( b.arama <@ a.arama and a.arama <@ >> b.arama ) >> ; >> QUERY >> PLAN >> >> --------------------------------------------------------------------------------------------------------- >> Nested Loop Left Join (cost=0.00..0.01 rows=1 width=4) (actual >> time=0.003..0.003 rows=0 loops=1) >> Join Filter: ((b.arama <@ a.arama) AND (a.arama <@ b.arama)) >> -> Seq Scan on _gc_tb a (cost=0.00..0.00 rows=1 width=66) (actual >> time=0.002..0.002 rows=0 loops=1) >> -> Seq Scan on _gc_cat b (cost=0.00..0.00 rows=1 width=70) (never >> executed) >> Planning time: 0.206 ms >> Execution time: 0.074 ms >> (6 filas) >> >> > OK, so this _gc_tb is empty which means that an extremely fast execution > time is not unsurprising. If the other version actually contains data I > would expect that it would take considerably longer... > > David J. > > >
