Re: [MASSMAIL]Re: 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.

Uhmmm, sería una buena idea usar explain como dice Anthony y apagar los
Indexes a ver que da me da la ligera impresión que los índices creados no
son los necesarios en esa caso.

>
> 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
>> <mailto: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 <http://t.id> as tecnicos_id,c.id <http://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 <http://t.id>, c.id <http://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 <http://t.id> as tecnicos_id,c.id <http://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 <http://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 <http://t_1.id> = t.id <http://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 <http://t_1.id>, c.id <http://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 <http://t.id> as tecnicos_id,c.id <http://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 <http://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 <http://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 <http://t.id>, c_1.id
>>> <http://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
>

--
Saludos,
Gilberto Castillo
ETECSA, La Habana, Cuba

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda