Re: Select sobre tabla con byte[] es lento

Podrías expresar ese CROSS JOIN COMO INNER JOIN?

FROM
informacion_ies.evidencias evidencia0_ INNER JOIN
informacion_ies.evidencias_concepto evidenciac1_

ON (evidencia0_.id_evidencia_concepto = evidenciac1_.id
AND evidencia0_.id_tabla = $1 AND evidenciac1_.tabla = $2)

Funcionalmente hacen lo mismo, pero déjame descartarlo

Claro

select evidencia0_.id as id5_, evidencia0_.descripcion_archivo as descripc2_5_,
evidencia0_.documento as documento5_, evidencia0_.id_evidencia_concepto as
id9_5_, evidencia0_.fecha_carga as fecha4_5_, evidencia0_.id_tabla as id5_5_,
evidencia0_.id_informacion_ies as id10_5_, evidencia0_.nombre_archivo as
nombre6_5_, evidencia0_.observaciones as observac7_5_,
evidencia0_.usuario_modificacion as usuario8_5_ from informacion_ies.evidencias
evidencia0_ cross join informacion_ies.evidencias_concepto evidenciac1_ where
evidencia0_.id_evidencia_concepto=evidenciac1_.id and evidencia0_.id_tabla=$1 and
evidenciac1_.tabla=$2 order by evidencia0_.id

Salu2

2013/4/22 Martín Marqués <martin(dot)marques(at)gmail(dot)com[1]>

Podes mandar la consulta?

El día 22 de abril de 2013 13:22, Fernando Paz <fpaz(at)engineer(dot)com[2]> escribió:

> Hola,>> Esta es la salida de explain analyze aunque no entiendo bien la
diferencias>>> QUERY PLAN>
--------------------------------------------------------------------------------------------------------------
-----------------------------------------------> Sort (cost=739.67..740.00 rows=131
width=144) (actual time=1.156..1.237> rows=171 loops=1)> Sort Key:
evidencia0_.id> Sort Method: quicksort Memory: 49kB> -> Nested Loop
(cost=0.00..735.06 rows=131 width=144) (actual> time=0.025..0.981 rows=171
loops=1)> -> Seq Scan on evidencias_concepto evidenciac1_
(cost=0.00..6.54> rows=96 width=8) (actual time=0.007..0.076 rows=96 loops=1)>
Filter: ((tabla)::text = 'ies'::text)> -> Index Scan using
ix_evidencias_con_tab on evidencias> evidencia0_ (cost=0.00..7.58 rows=1
width=144) (actual time=0.005..0.006> rows=2 loops=96)> Index Cond:
((id_evidencia_concepto = evidenciac1_.id) AND> (id_tabla = 1))>>> Gracias>>>
2013/4/22 Martín Marqués <martin(dot)marques(at)gmail(dot)com[1]>>>>> El día 22 de abril
de 2013 12:11, Fernando Paz <fpaz(at)engineer(dot)com[2]>>> escribió:>> > Holas,>>
>>> > De antemano gracias por ya ayuda.>> >>> > La cuestión es que tengo una
tabla (evidencias) en donde un campo>> > almacena>> > un archivo de tipo
documento (doc,odf,pdf,etc.)>> >>> > Esta ya a crecido bastante tiene unos 58000
registros que en gigas por>> > los>> > archivos se traduce en unos 30 GB>> >>>
> se suele hacer una consulta como>> >>> > select * from evidencias>> >
where>> > tipo = $1 and clase = $2>> >>> > Al hacer el explain toma
correctamente el índice pero su costo esta ahi>> > por>> > los 800, pero ejecutarla
se esta demorando más de 10 seg>>>> EXPLAIN ANALYZE además de "explicarte"
lo que el planner piensa hacer>> ejecuta la consulta para darte tiempos reales. Que
tiempos da explain>> analyze?>>>> > Porque?>> >>> > Sospecho que es
porque tiene almacenamiento de archivos... en ese caso>> > que>> > parámetro
debería optimizar para mejorar el tiempo?>>>> Cuantas filas, aproximadamente se
seleccionan con ese filtro?>>>> -->> Martín Marqués>> select 'martin.marques' ||
'@' || 'gmail.com[3]'>> DBA, Programador, Administrador>>

--Martín Marquésselect 'martin.marques' || '@' || '_gmail.com_'DBA, Programador,
Administrador

René Romero Benavides @iCodeiExist[4] @PgsqlMx[5]

Postgresql Tips en español para la comunidad de México e Hispanoamérica.
http://postgresql.org.mx[6]

--------
[1] mailto:martin(dot)marques(at)gmail(dot)com
[2] mailto:fpaz(at)engineer(dot)com
[3] http://gmail.com
[4] https://twitter.com/iCodeiExist
[5] https://twitter.com/PgsqlMx
[6] http://postgresql.org.mx