Re: consulta reinicia el motor de pgsql 9.5.1

Buenas tardes.

Si me lo puedes enviar ami te lo agradecería, me gustaría probarlo en mi
infraestructura.

Gracias de antemano
El 29/2/2016 5:05 p. m., "Felipe de Jesús Molina Bravo" <
fjmolinabravo(at)gmail(dot)com> escribió:

> Que tal!!
>
> En mi equipo portátil con fedora 23 (8 Gb RAM) dos containers (lxc):
>
> 1. Con postgresql 9.4.5 (2 Gb RAM)
> 2. Con postgresql 9.5.1 (2 Gb RAM)
>
> En el script de prueba que ejecuto se crean 2 tablas unlogged con la
> siguiente
> estructura:
>
> 1. CREATE unlogged TABLE _gc_tb as
> SELECT t[1]::INTEGER idb2,
> t[2]::INTEGER idc1,
> coalesce( t[3], '' ) rama,
> rama2arreglo(coalesce( t[3], '' )::varchar) arama
> FROM ....
>
> Indices:
> CREATE INDEX _gc_tb_arama on "_gc_tb" USING GIN (arama);
> CREATE INDEX _gc_tb_idb2idc1 on "_gc_tb" USING btree (idb2, idc1);
>
> No. de registros:
> 120130
>
> 2. CREATE unlogged TABLE _gc_cat AS
> SELECT idppicat,
> idprodxintegrar,
> tipo,
> valor,
> estado,
> idsll,
> idsfte,
> rama2arreglo(rama)
> arama,
> rama,
> rvar,
> nodec
> FROM ( SELECT x[1]::integer
> idppicat,
> x[2]::integer
> idprodxintegrar,
> x[3]::char(1)
> tipo,
> (NULLIF(x[4], ''))::numeric
> valor,
> x[5]::char(1)
> estado,
> x[6]::text
> rama,
> x[7]::text
> rvar,
> x[8]::text
> idsll,
> x[9]::text
> idsfte,
> x[10]::integer
> nodec
> FROM ....
>
>
> Indices:
> CREATE INDEX _gc_cat_arama on _gc_cat USING GIN (arama);
>
> No. de registros:
> 91932
>
>
> Al ejecutar la consulta en ambos servidores:
> EXPLAIN ANALYZE
> WITH
> du AS
> ( SELECT idprodxintegrar, a.idb2, a.idc1, tipo,
> valor, estado, idsll, idsfte, b.nodec,
> b.rama _match --sera nulo si no hay
> match
> FROM _gc_tb a
> LEFT join _gc_cat b
> on
> ( a.arama <@ b.arama and
> a.arama @> b.arama
> )
> )select * from du;
>
>
> Se obtiene:
>
> - pgsql 9.4.5:
> QUERY
> PLAN
>
> -----------------------------------------------------------------------------------------------------------------------------------------
> CTE Scan on du (cost=492858.81..498380.71 rows=276095 width=154)
> (actual time=18.380..34169.650 rows=120130 loops=1)
> CTE du
> -> Nested Loop Left Join (cost=0.03..492858.81 rows=276095
> width=154) (actual time=18.374..33851.684 rows=120130 loops=1)
> -> Seq Scan on _gc_tb a (cost=0.00..3235.30 rows=120130
> width=40) (actual time=0.009..50.643 rows=120130 loops=1)
> -> Bitmap Heap Scan on _gc_cat b (cost=0.03..4.06 rows=2
> width=178) (actual time=0.276..0.278 rows=1 loops=120130)
> Recheck Cond: ((a.arama <@ arama) AND (a.arama @>
> arama))
> Rows Removed by Index Recheck: 3
> Heap Blocks: exact=125574
> -> Bitmap Index Scan on _gc_cat_arama
> (cost=0.00..0.03 rows=2 width=0) (actual time=0.269..0.269 rows=4
> loops=120130)
> Index Cond: ((a.arama <@ arama) AND (a.arama @>
> arama))
> Planning time: 0.448 ms
> Execution time: 34207.916 ms
>
> - En pgsql 9.5.1
> - Nunca termina. Aproximadamente a los 5 minutos la maquina virtual se
> apaga.
>
> Lo mismo pasa si quito el explain analyze.
>
> Les comento que en otra estructura semejante pero en un servidor donde se
> tienen 2 virtuales con KVM (pgsql 9.5.1 y 9.4.3)el resultado en el virtual
> con
> pgsql 9.5.1 era parecido, excepto que en este reiniciaba el motor de
> postgres y
> sacaba a los usuarios conectados.
>
> Al monitorearlo nos damos cuenta de que se acaba la memoria y el swap.
>
> Tengo un script, que es con el que estoy probando; su tamaño es de 1.1 Mb
> (empacad); si alguien lo requiere para probar se lo mando a su correo...o
> en donde lo
> puedo poner?
>
> Alguna sugerencia de por donde investigar para corregir este problema?!!
>
> De antemano agradezco su atención
>
> Saludos!
>