Ahora hice lo siguiente, agregue a las tablas _tc_cat y _gc_tb el numero de
elementos en el arreglo del atributo "arama"
(coalesce(array_upper(arama,1),0) ne_arama,) y el left join lo cambie por:
....
SELECT idprodxintegrar
FROM _gc_tb a
LEFT join
_gc_cat b
on ( a.ne_arama = b.ne_arama and a.arama <@ b.arama )
...
y asi SI TERMINA!!! .... la consulta tarda "396103.695 ms" aprox 6
minutos. Esto mismo hago en pgsl 9.4.x y tarda 17 segundos!!!
Los explain analyzes son;
pgsql 9.5.1:
Nested Loop Left Join (cost=3.49..1915550.34 rows=41905028 width=4)
(actual time=148.809..124695.350 rows=120130 loops=1)
-> Seq Scan on _gc_tb a (cost=0.00..3321.30 rows=120130 width=70)
(actual time=0.131..34652.107 rows=120130 loops=1)
-> Bitmap Heap Scan on _gc_cat b (cost=3.49..14.39 rows=153 width=74)
(actual time=0.738..0.746 rows=1 loops=120130)
Recheck Cond: (a.arama <@ arama)
Filter: (a.ne_arama = ne_arama)
Rows Removed by Filter: 4
Heap Blocks: exact=127337
-> Bitmap Index Scan on _gc_cat_arama_gin (cost=0.00..3.45
rows=460 width=0) (actual time=0.692..0.692 rows=4 loops=120130)
Index Cond: (a.arama <@ arama)
Planning time: 138.930 ms
Execution time: 408882.203 ms
(11 filas)
pgsql 9.4.x:
Nested Loop Left Join (cost=3.49..1915550.34 rows=42163023 width=4)
(actual time=37.694..18399.908 rows=120130 loops=1)
-> Seq Scan on _gc_tb a (cost=0.00..3321.30 rows=120130 width=70)
(actual time=0.011..46.640 rows=120130 loops=1)
-> Bitmap Heap Scan on _gc_cat b (cost=3.49..14.39 rows=153 width=74)
(actual time=0.149..0.150 rows=1 loops=120130)
Recheck Cond: (a.arama <@ arama)
Filter: (a.ne_arama = ne_arama)
Rows Removed by Filter: 4
Heap Blocks: exact=127337
-> Bitmap Index Scan on _gc_cat_arama_gin (cost=0.00..3.45
rows=460 width=0) (actual time=0.145..0.145 rows=4 loops=120130)
Index Cond: (a.arama <@ arama)
Planning time: 0.312 ms
Execution time: 18419.634 ms
No se interpretarlos...voy a investigar .. pero sigo con muchas dudas:
- ¿por que con la anterior condición del left join (a.arama <@ b.arama and
a.arama @> b.arama) se reiniciaba pgsql 9.5.1? ...¿no habrá un bug?
- Quizas en pgsql 9.5.1 tenga parametros de configuración que tenga que
optimizar...¿sera?..¿alguna idea de cuales son??
seguimos!!
El 2 de marzo de 2016, 11:11, Felipe de Jesús Molina Bravo <
fjmolinabr...@gmail.com> escribió:
> Pues sigo sin poder hacer que funcione la consulta en pgsql 9.5.1...lo
> unico que he logrado es que al cambiar el "left join on"
> por un "left join using" si termina....y muy rapido.
>
> Pero no me sirve asi; se estan comparando 2 arreglos de texto; y para la
> logica de esta consulta dos arreglos son iguales si tienen los mismos
> elementos sin importar el orden, es decir:
> array['a', 'b' ] = array['b', 'a']
>
> en fin...sigo trabajando!!!
>
>
> El 29 de febrero de 2016, 19:06, Horacio Miranda <hmira...@gmail.com>
> escribió:
>
>> Dropbox ? y compartir el enlace publico ?
>>
>>
>> On 3/1/2016 2:04 PM, Jaime Casanova wrote:
>>
>>> 2016-02-29 16:34 GMT-05:00 Felipe de Jesús Molina Bravo
>>> <fjmolinabr...@gmail.com>:
>>>
>>>> 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 ....
>>>>
>>>>
>>> esto no sirve mucho como reporte, no hay forma de reproducir el problema
>>> así
>>>
>>> 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?
>>>>
>>>>
>>> si gustas, pasalo a mi correo para ver si puedo reproducir el problema
>>>
>>>
>
