Re: join super lento

Hola Mario

Ajuste los parámetros y no se ve gran cambio, tanto con el work_mem por
default como con el de 2048 MB, ya no adjunto imagen pues por el tamaño del
mensaje no lo permite la lista.

El 22 de febrero de 2016, 11:59, Hellmuth Vargas<hivs77(at)gmail(dot)com> escribió:

> Hola Mario
>
> Ajuste los parámetros y no se ve gran cambio, tanto con el work_mem por
> default como con el de 2048 MB:
>
> adjunto imagen
>
>
> ​
>
>
>
> El 22 de febrero de 2016, 11:20, Mario Soto Cordones<
> marioa(dot)soto(dot)cordones(at)gmail(dot)com> escribió:
>
>> Prueba con éstos parámetros, están en función a los 12Gb que tienes de
>> RAM.
>>
>>
>>
>>
>>
>> shared_buffers = 3GB
>>
>> effective_cache_size = 9GB
>>
>> work_mem = 8MB
>>
>>
>>
>>
>>
>> Saludos
>>
>>
>>
>> *De:* Hellmuth Vargas [mailto:hivs77(at)gmail(dot)com]
>> *Enviado el:* lunes, 22 de febrero de 2016 13:07
>> *Para:* Mario Soto Cordones <marioa(dot)soto(dot)cordones(at)gmail(dot)com>;
>> gilberto(dot)castillo(at)etecsa(dot)cu
>>
>> *CC:* Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org>
>> *Asunto:* Re: [pgsql-es-ayuda] join super lento
>>
>>
>>
>>
>>
>> Hola Lista
>>
>>
>>
>> envío los datos solicitados:
>>
>>
>>
>>
>>
>> max_connections = 200 -- tiene pgpool y en promedio mantiene 600 a 700
>> clientes con conexiones
>>
>> shared_buffers = 1024MB
>>
>> effective_cache_size = 8GB
>>
>> work_mem =16MB
>>
>>
>>
>>
>>
>> Los indices se los coloque para tratar de forzar un index only scan, los
>> removí todos (salvo los unique), quedando así el plan de ejecución:
>>
>>
>>
>> select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud, 1 as cant
>>
>> from public.ath_tecnicosv2 t
>>
>> left join public.ath_cajerosv2 c on
>> t.identificacionusuario=c.identificacion and t.fechamto=c.fecha
>>
>> where fecha >= '20160218' and fechamto >= '20160218'
>>
>> group by t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud,1
>>
>>
>>
>>
>>
>>
>>
>> Group (cost=106367.56..111610.64 rows=749012 width=179)
>>
>> -> Sort (cost=106367.56..106742.06 rows=749012 width=179)
>>
>> Sort Key: t.descripcionmovimiento, t.fechamto, t.horamto,
>> t.fechaact, t.horaact, t.usuario, t.identificacionusuario,
>> t.tipomovimientosusuario, c.fecha, c.nombre, c.regionalath, c.regionaltdv,
>> c.tiposolicitud
>>
>> -> Merge Join (cost=48584.01..52763.97 rows=749012 width=179)
>>
>> Merge Cond: ((c.identificacion = t.identificacionusuario)
>> AND (c.fecha = t.fechamto))
>>
>> -> Sort (cost=3071.50..3076.03 rows=9072 width=64)
>>
>> Sort Key: c.identificacion, c.fecha
>>
>> -> Seq Scan on ath_cajerosv2 c (cost=0.00..2952.22
>> rows=9072 width=64)
>>
>> Filter: (fecha >= '2016-02-18'::date)
>>
>> -> Materialize (cost=45512.45..45606.82 rows=94366
>> width=123)
>>
>> -> Sort (cost=45512.45..45559.63 rows=94366
>> width=123)
>>
>> Sort Key: t.identificacionusuario, t.fechamto
>>
>> -> Seq Scan on ath_tecnicosv2 t
>> (cost=0.00..40363.41 rows=94366 width=123)
>>
>> Filter: (fechamto >= '2016-02-18'::date)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> lleva en este momento 8 minutos y no termina el EXPLAIN ANALYZE, la
>> imagen cuando iba en 4 minutos
>>
>>
>>
>>
>> ​
>>
>>
>>
>>
>>
>> 2016-02-22 10:55 GMT-05:00 Mario Soto Cordones <
>> marioa(dot)soto(dot)cordones(at)gmail(dot)com>:
>>
>> Que valores tienes en estos parámetros:
>>
>>
>>
>>
>>
>> max_connections
>>
>> shared_buffers
>>
>> effective_cache_size
>>
>> work_mem
>>
>>
>>
>>
>>
>> Saludos
>>
>>
>>
>>
>>
>> *De:* pgsql-es-ayuda-owner(at)postgresql(dot)org [mailto:
>> pgsql-es-ayuda-owner(at)postgresql(dot)org] *En nombre de *Anthony Sotolongo
>> *Enviado el:* lunes, 22 de febrero de 2016 12:46
>> *Para:* Hellmuth Vargas <hivs77(at)gmail(dot)com>
>> *CC:* Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org>
>> *Asunto:* Re: [pgsql-es-ayuda] join super lento
>>
>>
>>
>> Puedes hacer el explain analyze con ese valor nuevo de work_mem 2048 MB
>> a ver que hizo con el Sort Method, pues me da la impresión que el
>> problema esta ahí en el Sort Method
>>
>> Creo que no se trata de las cantidad de JOIN, hay que detectar donde es
>> el cuello de botella en el plan.
>>
>> saludos
>>
>> On 22/02/16 12:38, Hellmuth Vargas wrote:
>>
>>
>>
>> Hola Anthony
>>
>>
>>
>> Gracias por la pregunta: actualmente se tiene configurado así la maquina:.
>>
>>
>>
>> cat postgresql.conf | grep -i 'work_mem'
>>
>>
>>
>> work_mem = 16MB # min 64kB
>>
>> maintenance_work_mem = 512MB # min 1MB
>>
>>
>>
>> Aunque también probé colocando hasta 2048 MB y no cambia en mucho la
>> verdad
>>
>>
>>
>>
>>
>> set local work_mem='2048 MB'
>>
>> select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud, 1 as cant
>>
>> from public.ath_tecnicosv2 t
>>
>> left join public.ath_cajerosv2 c on
>> t.identificacionusuario=c.identificacion and t.fechamto=c.fecha
>>
>> where fecha >= '20160218' and fechamto >= '20160218'
>>
>> group by t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud,1
>>
>>
>>
>>
>>
>> Group (cost=60388.03..65631.12 rows=749012 width=179)
>>
>> -> Sort (cost=60388.03..60762.54 rows=749012 width=179)
>>
>> Sort Key: t.descripcionmovimiento, t.fechamto, t.horamto,
>> t.fechaact, t.horaact, t.usuario, t.identificacionusuario,
>> t.tipomovimientosusuario, c.fecha, c.nombre, c.regionalath, c.regionaltdv,
>> c.tiposolicitud
>>
>> -> Merge Join (cost=7.77..6784.44 rows=749012 width=179)
>>
>> Merge Cond: ((c.fecha = t.fechamto) AND (c.identificacion =
>> t.identificacionusuario))
>>
>> -> Index Only Scan using idx_ath_cajerosv2_comp on
>> ath_cajerosv2 c (cost=0.08..169.88 rows=9072 width=64)
>>
>> Index Cond: (fecha >= '2016-02-18'::date)
>>
>> -> Materialize (cost=0.11..2533.11 rows=94366 width=123)
>>
>> -> Index Only Scan using idx_ath_tecnicosv2_comp on
>> ath_tecnicosv2 t (cost=0.11..2485.92 rows=94366 width=123)
>>
>> Index Cond: (fechamto >= '2016-02-18'::date)
>>
>>
>>
>>
>>
>>
>> ​
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Y pues tengo otras tablas muchísimo mas grandes (35 Millones de
>> registros) con consultas con varios join y no se tardan tanto ( en el mismo
>> cluster de base de datos)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2016-02-22 10:13 GMT-05:00 Anthony Sotolongo <asotolongo(at)gmail(dot)com>:
>>
>> Hola Hellmuth, que valor tiene tu work_mem a la hora de realizar esa
>> consulta?, pues se observa varios:
>> Sort Method: external merge Disk: 247448kB
>>
>> lo cual indica que esta realizando esa operación de ordenamiento en
>> disco!!!
>>
>> Saludos
>> Anthony
>>
>>
>>
>> On 22/02/16 11:55, Hellmuth Vargas wrote:
>>
>>
>>
>> Hola Lista
>>
>> Les tengo el siguiente desafio pues no he podido dar con el tema, tengo
>> dos tablas
>>
>>
>>
>> CREATE TABLE ath_tecnicosv2
>>
>> (
>>
>> descripcionmovimiento character varying(160),
>>
>> fechamto date,
>>
>> horamto character varying(8),
>>
>> fechaact character varying(8),
>>
>> horaact character varying(8),
>>
>> usuario character varying(50),
>>
>> identificacionusuario bigint,
>>
>> tipomovimientosusuario character varying(25),
>>
>> id bigserial NOT NULL
>>
>> )
>>
>> WITH (
>>
>> OIDS=FALSE
>>
>> );
>>
>>
>>
>> -- tamaño: 1639200 registros
>>
>>
>>
>> CREATE UNIQUE INDEX idx_u_ath_tecnicosv2_id
>>
>> ON ath_tecnicosv2
>>
>> USING btree
>>
>> (id);
>>
>>
>>
>> CREATE INDEX idx_ath_tecnicosv2_comp
>>
>> ON ath_tecnicosv2
>>
>> USING btree
>>
>> (fechamto, identificacionusuario, descripcionmovimiento COLLATE
>> pg_catalog."default", horamto COLLATE pg_catalog."default", fechaact
>> COLLATE pg_catalog."default", horaact COLLATE pg_catalog."default", usuario
>> COLLATE pg_catalog."default", tipomovimientosusuario COLLATE
>> pg_catalog."default");
>>
>>
>>
>> CREATE INDEX idx_ath_tecnicosv2_fecha2
>>
>> ON public.ath_tecnicosv2
>>
>> USING btree
>>
>> (fechamto asc, identificacionusuario asc,id);
>>
>>
>>
>>
>>
>> CREATE TABLE ath_cajerosv2
>>
>> (
>>
>> fecha date,
>>
>> nombre character varying(60),
>>
>> regionalath character varying(24),
>>
>> regionaltdv character varying(54),
>>
>> tiposolicitud character varying(10),
>>
>> id_usuario character varying(4),
>>
>> identificacion bigint,
>>
>> usuario character varying(36),
>>
>> cant bigint,
>>
>> id bigserial NOT NULL
>>
>> )
>>
>> WITH (
>>
>> OIDS=FALSE
>>
>> );
>>
>>
>>
>> -- tamaño: 132050 registros
>>
>>
>>
>> CREATE UNIQUE INDEX idx_u_ath_cajerosv2_id
>>
>> ON ath_cajerosv2
>>
>> USING btree
>>
>> (id);
>>
>>
>>
>> CREATE INDEX idx_ath_cajerosv2_comp
>>
>> ON ath_cajerosv2
>>
>> USING btree
>>
>> (fecha, identificacion, nombre COLLATE pg_catalog."default",
>> regionalath COLLATE pg_catalog."default", regionaltdv COLLATE
>> pg_catalog."default", tiposolicitud COLLATE pg_catalog."default");
>>
>>
>>
>> CREATE INDEX idx_ath_cajerosv2_fecha2
>>
>> ON public.ath_cajerosv2
>>
>> USING btree
>>
>> (fecha asc, identificacion asc,id);
>>
>>
>>
>> -- consulta Básica Inicial:
>>
>>
>>
>> select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud, 1 as cant
>>
>> from public.ath_tecnicosv2 t
>>
>> join public.ath_cajerosv2 c on t.identificacionusuario=c.identificacion
>> and t.fechamto=c.fecha
>>
>> where fecha >= '20160218' and fechamto >= '20160218'
>>
>> group by t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud,1
>>
>>
>>
>>
>>
>> -- plan de ejecucion
>>
>>
>>
>> Group (cost=60388.03..65631.12 rows=749012 width=179)
>>
>> -> Sort (cost=60388.03..60762.54 rows=749012 width=179)
>>
>> Sort Key: t.descripcionmovimiento, t.fechamto, t.horamto,
>> t.fechaact, t.horaact, t.usuario, t.identificacionusuario,
>> t.tipomovimientosusuario, c.fecha, c.nombre, c.regionalath, c.regionaltdv,
>> c.tiposolicitud
>>
>> -> Merge Join (cost=7.77..6784.44 rows=749012 width=179)
>>
>> Merge Cond: ((c.fecha = t.fechamto) AND (c.identificacion =
>> t.identificacionusuario))
>>
>> -> Index Only Scan using idx_ath_cajerosv2_comp on
>> ath_cajerosv2 c (cost=0.08..169.88 rows=9072 width=64)
>>
>> Index Cond: (fecha >= '2016-02-18'::date)
>>
>> -> Materialize (cost=0.11..2533.11 rows=94366 width=123)
>>
>> -> Index Only Scan using idx_ath_tecnicosv2_comp on
>> ath_tecnicosv2 t (cost=0.11..2485.92 rows=94366 width=123)
>>
>> Index Cond: (fechamto >= '2016-02-18'::date)
>>
>>
>>
>>
>>
>>
>> ​
>>
>> Alcanzamos a esperar 45 minutos por el resultado de la consulta y no
>> había terminado.
>>
>>
>>
>> Entonces empezamos a revisar cada tabla: cada una por separado no se
>> demora la consulta:
>>
>> -------------
>>
>> -- tabla ath_tecnicosv2
>>
>>
>>
>> select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario
>>
>> from public.ath_tecnicosv2 t
>>
>> where t.fechamto between '20160218' and now()
>>
>> order by t.identificacionusuario,t.fechamto
>>
>>
>>
>>
>>
>> Sort (cost=7682.15..7729.33 rows=94366 width=123) (actual
>> time=192.756..216.720 rows=96462 loops=1)
>>
>> Sort Key: identificacionusuario, fechamto
>>
>> Sort Method: external merge Disk: 11744kB
>>
>> -> Index Only Scan using idx_ath_tecnicosv2_comp on ath_tecnicosv2 t
>> (cost=0.11..2533.11 rows=94366 width=123) (actual time=1.382..60.523
>> rows=96462 loops=1)
>>
>> Index Cond: ((fechamto >= '2016-02-18'::date) AND (fechamto <=
>> now()))
>>
>> Heap Fetches: 0
>>
>> Total runtime: 223.940 ms
>>
>>
>>
>>
>> ​
>>
>>
>>
>>
>>
>> -----------------------
>>
>> -- tabla ath_cajerosv2
>>
>>
>>
>> select c.fecha, c.nombre, c.regionalath, c.regionaltdv,
>> c.tiposolicitud,c.identificacion
>>
>> from public.ath_cajerosv2 c
>>
>> where fecha between '20160218' and now()
>>
>> order by c.identificacion,c.fecha
>>
>> plan 3
>>
>>
>>
>> Sort (cost=293.69..298.22 rows=9072 width=64) (actual time=9.959..10.501
>> rows=9046 loops=1)
>>
>> Sort Key: identificacion, fecha
>>
>> Sort Method: quicksort Memory: 1641kB
>>
>> -> Index Only Scan using idx_ath_cajerosv2_comp on ath_cajerosv2 c
>> (cost=0.08..174.42 rows=9072 width=64) (actual time=1.174..6.215 rows=9046
>> loops=1)
>>
>> Index Cond: ((fecha >= '2016-02-18'::date) AND (fecha <= now()))
>>
>> Heap Fetches: 0
>>
>> Total runtime: 10.928 ms
>>
>>
>>
>>
>>
>>
>> ​
>>
>>
>>
>> por lo tanto el problema es el JOIN , realice un JOIN con solo los ID
>> (no se demora mucho):
>>
>>
>>
>> ----------------------
>>
>>
>>
>> select t.id as tecnicos_id,c.id as cajeros_id
>>
>> from public.ath_tecnicosv2 t
>>
>> join public.ath_cajerosv2 c on t.identificacionusuario=c.identificacion
>> and t.fechamto=c.fecha
>>
>> where fecha >= '20160218' and fechamto >= '20160218'
>>
>> group by 1,2
>>
>>
>>
>>
>>
>>
>>
>> --- plan 4
>>
>>
>>
>> Group (cost=27378.71..28502.23 rows=749012 width=16) (actual
>> time=14665.728..20729.334 rows=9736174 loops=1)
>>
>> -> Sort (cost=27378.71..27753.21 rows=749012 width=16) (actual
>> time=14665.725..18538.695 rows=9736174 loops=1)
>>
>> Sort Key: t.id, c.id
>>
>> Sort Method: external merge Disk: 247448kB
>>
>> -> Merge Join (cost=4.34..5263.12 rows=749012 width=16) (actual
>> time=2.168..2993.563 rows=9736174 loops=1)
>>
>> Merge Cond: ((c.fecha = t.fechamto) AND (c.identificacion =
>> t.identificacionusuario))
>>
>> -> Index Only Scan using idx_ath_cajerosv2_fecha2 on
>> ath_cajerosv2 c (cost=0.08..100.58 rows=9072 width=20) (actual
>> time=1.027..12.524 rows=9046 loops=1)
>>
>> Index Cond: (fecha >= '2016-02-18'::date)
>>
>> Heap Fetches: 0
>>
>> -> Materialize (cost=0.09..1081.08 rows=94366 width=20)
>> (actual time=1.131..1006.430 rows=9738392 loops=1)
>>
>> -> Index Only Scan using idx_ath_tecnicosv2_fecha2
>> on ath_tecnicosv2 t (cost=0.09..1033.90 rows=94366 width=20) (actual
>> time=1.128..20.970 rows=96459 loops=1)
>>
>> Index Cond: (fechamto >= '2016-02-18'::date)
>>
>> Heap Fetches: 0
>>
>> Total runtime: 21264.042 ms
>>
>> ​
>>
>> -----
>>
>> Por lo tanto, reescribí la consulta, primero haciendo el JOIN entre ID
>> y luego vinculando las tablas con estos mismos IDS pero no funciono, se
>> sigue demorando mucho... si hago JOIN por las tablas por separado no se
>> demoran:
>>
>> select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario
>>
>> from (
>>
>> select t.id as tecnicos_id,c.id as cajeros_id
>>
>> from public.ath_tecnicosv2 t
>>
>> join public.ath_cajerosv2 c on t.identificacionusuario=c.identificacion
>> and t.fechamto=c.fecha
>>
>> where fecha >= '20160218' and fechamto >= '20160218'
>>
>> group by 1,2
>>
>> ) as x
>>
>> join public.ath_tecnicosv2 t on t.id=x.tecnicos_id
>>
>> plan 5
>>
>> Merge Join (cost=27378.79..81818.32 rows=749012 width=123) (actual
>> time=18134.833..28281.834 rows=9736174 loops=1)
>>
>> Merge Cond: (t_1.id = t.id)
>>
>> -> Group (cost=27378.71..28502.23 rows=749012 width=16) (actual
>> time=17462.700..23149.037 rows=9736174 loops=1)
>>
>> -> Sort (cost=27378.71..27753.21 rows=749012 width=16) (actual
>> time=17462.698..21212.132 rows=9736174 loops=1)
>>
>> Sort Key: t_1.id, c.id
>>
>> Sort Method: external merge Disk: 247448kB
>>
>> -> Merge Join (cost=4.34..5263.12 rows=749012 width=16)
>> (actual time=0.097..3588.954 rows=9736174 loops=1)
>>
>> Merge Cond: ((c.fecha = t_1.fechamto) AND (
>> c.identificacion = t_1.identificacionusuario))
>>
>> -> Index Only Scan using idx_ath_cajerosv2_fecha2 on
>> ath_cajerosv2 c (cost=0.08..100.58 rows=9072 width=20) (actual
>> time=0.057..14.490 rows=9046 loops=1)
>>
>> Index Cond: (fecha >= '2016-02-18'::date)
>>
>> Heap Fetches: 0
>>
>> -> Materialize (cost=0.09..1081.08 rows=94366
>> width=20) (actual time=0.038..1253.519 rows=9738392 loops=1)
>>
>> -> Index Only Scan using
>> idx_ath_tecnicosv2_fecha2 on ath_tecnicosv2 t_1 (cost=0.09..1033.90
>> rows=94366 width=20) (actual time=0.035..25.707 rows=96459 loops=1)
>>
>> Index Cond: (fechamto >=
>> '2016-02-18'::date)
>>
>> Heap Fetches: 0
>>
>> -> Index Scan using idx _u_ath_tecnicosv2_id on ath_tecnicosv2 t
>> (cost=0.09..46129.90 rows=1639202 width=131) (actual time=1.746..1950.852
>> rows=11281027 loops=1)
>>
>> Total runtime: 28768.255 ms
>>
>> ​
>>
>> -----------------
>>
>> select
>>
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud
>>
>> from (
>>
>> select t.id as tecnicos_id,c.id as cajeros_id
>>
>> from public.ath_tecnicosv2 t
>>
>> join public.ath_cajerosv2 c on t.identificacionusuario=c.identificacion
>> and t.fechamto=c.fecha
>>
>> where fecha >= '20160218' and fechamto >= '20160218'
>>
>> group by 1,2
>>
>> ) as x
>>
>> join public.ath_cajerosv2 c on c.id=x.cajeros_id
>>
>> plan 6
>>
>> Hash Join (cost=32278.13..47788.27 rows=749012 width=56) (actual
>> time=17682.541..29054.853 rows=9736174 loops=1)
>>
>> Hash Cond: (x.cajeros_id = c.id)
>>
>> -> Subquery Scan on x (cost=27378.71..31498.27 rows=749012 width=8)
>> (actual time=17588.940..24201.101 rows=9736174 loops=1)
>>
>> -> Group (cost=27378.71..28502.23 rows=749012 width=16) (actual
>> time=17588.939..23095.463 rows=9736174 loops=1)
>>
>> -> Sort (cost=27378.71..27753.21 rows=749012 width=16)
>> (actual time=17588.936..21161.819 rows=9736174 loops=1)
>>
>> Sort Key: t.id, c_1.id
>>
>> Sort Method: external merge Disk: 247448kB
>>
>> - > Merge Join (cost=4.34..5263.12 rows=749012 wid
>> th=16) (actual time=0.076..3827.427 rows=9736174 loops=1)
>>
>> Merge Cond: ((c_1.fecha = t.fechamto) AND
>> (c_1.identificacion = t.identificacionusuario))
>>
>> -> Index Only Scan using
>> idx_ath_cajerosv2_fecha2 on ath_cajerosv2 c_1 (cost=0.08..100.58 rows=9072
>> width=20) (actual time=0.039..16.084 rows=9046 loops=1)
>>
>> Index Cond: (fecha >= '2016-02-18'::date)
>>
>> Heap Fetches: 0
>>
>> -> Materialize (cost=0.09..1081.08 rows=94366
>> width=20) (actual time=0.031..1317.914 rows=9738392 loops=1)
>>
>> -> Index Only Scan using
>> idx_ath_tecnicosv2_fecha2 on ath_tecnicosv2 t (cost=0.09..1033.90
>> rows=94366 width=20) (actual time=0.029..23.961 rows=96459 loops=1)
>>
>> Â Index Cond: (fechamto >=
>> '2016-02-18'::date)
>>
>> Heap Fetches: 0
>>
>> -> Hash (cost=2886.20..2886.20 rows=132050 width=64) (actual
>> time=92.976..92.976 rows=132050 loops=1)
>>
>> Buckets: 8192 Batches: 4 Memory Usage: 3281kB
>>
>> -> Seq Scan on ath_cajerosv2 c (cost=0.00..2886.20 rows=132050
>> width=64) (actual time=0.451..43.008 rows=132050 loops=1)
>>
>> Total runtime: 29573.302 m
>>
>> ​
>>
>> Entonces no se pueda ser!!!
>>
>> incluso (a manera de comentario) replantee la consultas asi y tampoco:
>>
>> with base1 as (
>>
>> select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario
>>
>> from (
>>
>> select t.identificacionusuario,t.fechamto from public.ath_tecnicosv2 t
>> where fechamto >= '20160218'
>>
>> intersect
>>
>> select c.identificacion,c.fecha from public.ath_cajerosv2 c where fecha
>> >= '20160218'
>>
>> ) as x
>>
>> join public.ath_tecnicosv2 t on
>> (t.identificacionusuario,t.fechamto)=(x.identificacionusuario,x.fechamto)
>>
>> ), base2 as (
>>
>> select x.identificacionusuario,x.fechamto,c.fecha, c.nombre,
>> c.regionalath, c.regionaltdv, c.tiposolicitud
>>
>> from (
>>
>> select t.identificacionusuario,t.fechamto from public.ath_tecnicosv2 t
>> where fechamto >= '20160218'
>>
>> intersect
>>
>> select c.identificacion,c.fecha from public.ath_cajerosv2 c where fecha
>> >= '20160218'
>>
>> ) as x
>>
>> join public.ath_cajerosv2 c on
>> (c.identificacion,c.fecha)=(x.identificacionusuario,x.fechamto)
>>
>> )
>>
>> select u.descripcionmovimiento, u.fechamto, u.horamto, u.fechaact,
>> u.horaact, u.usuario, u.identificacionusuario, u.tipomovimientosusuario,
>> u.fecha, u.nombre, u.regionalath, u.regionaltdv, u.tiposolicitud, 1 as cant
>>
>> from (
>>
>> select
>>
>> x.descripcionmovimiento, x.fechamto, x.horamto, x.fechaact, x.horaact,
>> x.usuario, x.identificacionusuario, x.tipomovimientosusuario, y.fecha, y.n
>> ombre, y.regionalath, y.regionaltdv,
>> y.tiposolicitud,y.identificacionusuario as
>> identificacionusuario2,y.fechamto as fechamto2
>>
>> from base1 as x
>>
>> cross join base2 as y
>>
>> ) as u where u.identificacionusuario=u.identificacionusuario2 and
>> u.fechamto=u.fechamto2
>>
>> order by 2,3,7
>>
>> ---
>>
>> Sort (cost=8260.00..8260.48 rows=961 width=1010)
>>
>> Sort Key: x.fechamto, x.horamto, x.identificacionusuario
>>
>> CTE base1
>>
>> -> Nested Loop (cost=0.19..3929.54 rows=21842 width=123)
>>
>> -> Subquery Scan on x_1 (cost=0.08..1528.40 rows=533 width=12)
>>
>> -> HashSetOp Intersect (cost=0.08..1526.27 rows=533
>> width=12)
>>
>> -> Append (cost=0.08..1422.83 rows=103438
>> width=12)
>>
>> -> Subquery Scan on "*SELECT* 2"
>> (cost=0.08..125.87 rows=9072 width=12)
>>
>> -> Index Only Scan using
>> idx_ath_cajerosv2_fecha on ath_cajerosv2 c (cost=0.08..89.58 rows=9072
>> width=12)
>>
>> Index Cond: (fecha >=
>> '2016-02-18'::date)
>>
>> -> Subquery Scan on "*SELECT* 1"
>> (cost=0.09..1296.96 rows=94366 width=12)
>>
>> -> Index Only Scan using
>> idx_ath_tecnicosv2_fecha on ath_tecnicosv2 t_1 (cost=0.09..919.50
>> rows=94366 width=12)
>>
>> Index Cond: (fechamto >=
>> '2016-02-18'::date)
>>
>> -> Index Only Scan using idx_ath_tecnicosv2_comp on
>> ath_tecnicosv2 t (cost=0.11..4.08 rows=107 width=123)
>>
>> Index Cond: ((fechamto = x_1.fechamto) AND
>> (identificacionusuario = x_1.identificacionusuario))
>>
>> CTE base2
>>
>> -> Nested Loop (cost=0.17..2175.54 rows=1760 width=68)
>>
>> -> Subquery Scan on x_2 (cost=0.08..1528.40 rows=533 width=12)
>>
>> -> HashSetOp Intersect (cost=0.08..1526.27 rows=533
>> width=12)
>>
>> -> Append (cost=0.08..1422.83 rows=103438
>> width=12)
>>
>> -> Subquery Scan on "*SELECT* 2_1"
>> (cost=0.08..125.87 rows=9072 width=12)
>>
>> -> Index Only Scan using
>> idx_ath_cajerosv2_fecha on ath_cajerosv2 c_2 (cost=0.08..89.58 rows=9072
>> width=12)
>>
>> Index Cond: (fecha >=
>> '2016-02-18'::date)
>>
>> -> Subquery Scan on "*SELECT* 1_1"
>> (cost=0.09..1296.96 rows=94366 width=12)
>>
>> -> Index Only Scan using
>> idx_ath_tecnicosv2_fecha on ath_tecnicosv2 t_2 (cost=0.09..919.50
>> rows=94366 width=12)
>>
>> Index Cond: (fechamto >=
>> '2016-02-18'::date)
>>
>> -> Index Only Scan using idx_ath_cajerosv2_comp on
>> ath_cajerosv2 c_1 (cost=0.08..1.15 rows=17 width=64)
>>
>> Index Cond: ((fecha = x_2.fechamto) AND (identificacion =
>> x_2.identificacionusuario))
>>
>> -> Hash Join (cost=22.88..2145.40 rows=961 width=1010)
>>
>> Hash Cond: ((x.identificacionusuario = y.identificacionusuario)
>> AND (x.fechamto = y.fechamto))
>>
>> -> CTE Scan on base1 x (cost=0.00..174.74 rows=21842 width=638)
>>
>> -> Hash (cost=14.08..14.08 rows=1760 width=384)
>>
>> -> CTE Scan on base2 y (cost=0.00..14.08 rows=1760
>> width=384)
>>
>> ​
>>
>> He cambiado la estructura de las tablas: antes todos los campos eran del
>> tipo TEXT y por lo tanto la tablas tenían ademas tablas TOAST y supuse que
>> el JOIN con estas era lo que estaba penalizando.
>>
>> Las especificaciones, es un PostgreSQL 9.4.5, corriendo en un CentOS 6
>> con discos de estado solido. 12 GB de RAM, 12
>>
>> Lista les agradezco sus comentratios el ideas de que puede ser el
>> probelma.
>>
>> --
>>
>> Cordialmente, Ing. Hellmuth I. Vargas S. Esp. Telemática y Negocios por
>> Internet
>>
>> Oracle Database 10g Administrator Certified Associate
>>
>> EnterpriseDB Certified PostgreSQL 9.3 Associate
>>
>> --
>>
>> Cordialmente, Ing. Hellmuth I. Vargas S. Esp. Telemática y Negocios por
>> Internet
>>
>> Oracle Database 10g Administrator Certified Associate
>>
>> EnterpriseDB Certified PostgreSQL 9.3 Associate
>>
>>
>>
>>
>>
>> --
>>
>> Cordialmente,
>>
>> Ing. Hellmuth I. Vargas S.
>> Esp. Telemática y Negocios por Internet
>>
>> Oracle Database 10g Administrator Certified Associate
>>
>> EnterpriseDB Certified PostgreSQL 9.3 Associate
>>
>>
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>

--
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate