Re: query reboot pgsql 9.5.1

[Felipe de Jesús Molina Bravo <fjmolinabravo@xxxxxxxxx>]

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.johnston@xxxxxxxxx>:

On Fri, Mar 4, 2016 at 2:16 PM, Felipe de Jesús Molina Bravo <fjmolinabravo@xxxxxxxxx> 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.

​