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" < fjmolinabr...@gmail.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! >
