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!
