Re: query reboot pgsql 9.5.1

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(dot)g(dot)johnston(at)gmail(dot)com>:

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