http://momjian.us/main/writings/pgsql/optimizer.pdf
Excelente!
Guillermo Villanueva
El 26 de mayo de 2014, 20:25, Guillermo E. Villanueva <
[email protected]> escribió:
> Jaja que buena idea Alvaro, espero encontrar acá en Salta alguno que me
> pueda ayudar y cobrarse esa(s) cerveciña(s)
Jaja que buena idea Alvaro, espero encontrar acá en Salta alguno que me
pueda ayudar y cobrarse esa(s) cerveciña(s) ;-)
Guillermo Villanueva
El 26 de mayo de 2014, 16:16, Alvaro Herrera escribió:
> Guillermo E. Villanueva escribió:
> > Ok muchas gracias Martín y Alvaro.
> > Es verdad Alvaro,
Guillermo E. Villanueva escribió:
> Ok muchas gracias Martín y Alvaro.
> Es verdad Alvaro, no estoy leyendo correctamente el plan, conocés alguna
> guía que me sugieras para entenderlo mejor?
Hay presentaciones de Bruce Momjian y otras personas en los archivos de
presentaciones de PGCon. Normalme
Ok muchas gracias Martín y Alvaro.
Es verdad Alvaro, no estoy leyendo correctamente el plan, conocés alguna
guía que me sugieras para entenderlo mejor?
Desde muchas gracias.
Guillermo Villanueva
El 26 de mayo de 2014, 15:38, Alvaro Herrera escribió:
> Guillermo E. Villanueva escribió:
>
> >
Guillermo E. Villanueva escribió:
> Te pido si vos tenés en claro porque no usa el índice para joins de tablas
> tan grandes que me lo expliques porque lo que me comentás no creo que
> justifique el descarte del índice, yo entiendo que por cada fila de h debe
> buscar la coincidencia de la fila de
El 26/05/14 15:07, Guillermo E. Villanueva escribió:
> Martín, tal como lo decís, sin límit el planificador resuelve el join con
> seq scan y al poner limit ya utiliza los índices.
> Te pido si vos tenés en claro porque no usa el índice para joins de tablas
> tan grandes que me lo expliques porque
Martín, tal como lo decís, sin límit el planificador resuelve el join con
seq scan y al poner limit ya utiliza los índices.
Te pido si vos tenés en claro porque no usa el índice para joins de tablas
tan grandes que me lo expliques porque lo que me comentás no creo que
justifique el descarte del índ
El día 26 de mayo de 2014, 10:23, Guillermo E. Villanueva
escribió:
> explain
> select *
> from
> nacer.historicotemp h
> inner join nacer.smiafiliados s on
> h.clavebeneficiario = s.clavebeneficiario;
>
> Con siguiente resultado
>
> "Hash Join (cost=5.39..1817942.71 rows=5692774 width=1002)"
Hola. Creo que es porque no estas haciendo where de nada, y traer todos los
registros equivale a un full scan de las tablas.
El may 26, 2014 9:24 AM, "Guillermo E. Villanueva"
escribió:
> Buenos días, se que ya hubieron muchas preguntas al respecto pero este
> caso me llama la atención y los mole
2012/11/5 Pedro Ricardo :
> Espero me puedan dar una mano para ir avanzando con este tema del explain.
Un documento bastante interesante hizo público Guillaume Lelarge,
después del pgconf 2012, sobre el tema y se llama «Understanding
Explain». En este explica desde lo más elemental -y ahí están tu
Pedro Ricardo wrote:
> 0.00 = es el valor de la primera - Es correcto ¿?
> 133.42 = es el valor de la ultima - Es correcto ¿?
>
> Son estimaciones entonces ?
Sí a las tres preguntas, si con "es el valor de" quieres decir "es el
valor estimado, en unidades totalmente arbitrarias, de lo que tardarí
Pedro Ricardo escribió:
> Hola amigos, estoy iniciándome en esto del analizador de consultas y tengo
> algunas dudas que agradecería me comenten.
> *
> *
> *>* *explain SELECT * FROM venta*
> *>> Seq Scan on venta (cost=0.00..133.42 rows=4842 width=219)*
Ojo, los valores de esta línea son estimac
> Hola amigos, estoy iniciándome en esto del analizador de consultas y tengo
> algunas dudas que agradecería me comenten.
> *
> *
> *>* *explain SELECT * FROM venta*
> *>> Seq Scan on venta (cost=0.00..133.42 rows=4842 width=219)*
> *
> *
> Según leí
> *
> *
> *cost=0.00..133.42 =* indica el tie
Excerpts from Alejandro D. Burne's message of jue may 13 20:26:10 -0400 2010:
> El 13 de mayo de 2010 19:59, Raúl Andrés Duque Murillo <
> [email protected]> escribió:
>
> > No todos los planes tienen los problemas que plantea Alejandro. Si tu
> >> función no tiene este problema, no es necesa
El 13 de mayo de 2010 19:59, Raúl Andrés Duque Murillo <
[email protected]> escribió:
> No todos los planes tienen los problemas que plantea Alejandro. Si tu
>> función no tiene este problema, no es necesario hacer nada.
>>
>
> Gracias Alvaro. Que condiciones deben darse para que se presente
No todos los planes tienen los problemas que plantea Alejandro. Si tu
función no tiene este problema, no es necesario hacer nada.
Gracias Alvaro. Que condiciones deben darse para que se presente este
problema?
-
Enviado a la lista de correo pgsql-es-ayuda ([email protected])
Pa
Excerpts from Raúl Andrés Duque Murillo's message of jue may 13 17:13:30 -0400
2010:
> Ninguna otra alternativa?
No todos los planes tienen los problemas que plantea Alejandro. Si tu
función no tiene este problema, no es necesario hacer nada.
> (almenos yo) trato al m\xc3\xa1ximo evitar el uso
que TODAS las sentencias en una funci\xc3\xb3n pl/pgSQL deber\xc3\xadan
ser ejecutadas
usando SQL DIN\xc3\x81MICO (cadenas) para evitar utilizar planes
guardados?
Efectivamente
Ninguna otra alternativa?
(almenos yo) trato al máximo evitar el uso de sql dinámico ya que complican
mucho la dep
Excerpts from Raúl Andrés Duque Murillo's message of jue may 13 15:55:16 -0400
2010:
> > Dale una le\xc3\xadda a esto a ver si te ayuda, y me cuentas:
> >
> > http://alvherre.livejournal.com/4324.html
>
> A qu\xc3\xa9 te refieres con "normalmente es posible solucionar estos
> problemas
> usando
Dale una leída a esto a ver si te ayuda, y me cuentas:
http://alvherre.livejournal.com/4324.html
A qué te refieres con "normalmente es posible solucionar estos problemas
usando EXECUTE para evitar el uso de un plan preparado"?
que TODAS las sentencias en una función pl/pgSQL deberían ser eje
El día 13 de mayo de 2010 14:56, Alejandro D. Burne
escribió:
> El 13 de mayo de 2010 14:51, Silvio Quadri escribió:
>>
>> 2010/5/13 Alejandro D. Burne :
>> > El 13 de mayo de 2010 12:41, Alvaro Herrera
>> > escribió:
>> >>
>> >> Excerpts from Alejandro D. Burne's message of jue may 13 09:53:58
El 13 de mayo de 2010 14:51, Silvio Quadri escribió:
> 2010/5/13 Alejandro D. Burne :
> > El 13 de mayo de 2010 12:41, Alvaro Herrera
> > escribió:
> >>
> >> Excerpts from Alejandro D. Burne's message of jue may 13 09:53:58 -0400
> >> 2010:
> >> > Tengo un store procedure que dentro tiene una co
2010/5/13 Alejandro D. Burne :
> El 13 de mayo de 2010 12:41, Alvaro Herrera
> escribió:
>>
>> Excerpts from Alejandro D. Burne's message of jue may 13 09:53:58 -0400
>> 2010:
>> > Tengo un store procedure que dentro tiene una consulta, esa consulta al
>> > momento de correrla dentro del SP me dem
El 13 de mayo de 2010 12:41, Alvaro Herrera escribió:
> Excerpts from Alejandro D. Burne's message of jue may 13 09:53:58 -0400
> 2010:
> > Tengo un store procedure que dentro tiene una consulta, esa consulta al
> > momento de correrla dentro del SP me demora unos 36 segundos, ahora bien;
> si
> >
Excerpts from Alejandro D. Burne's message of jue may 13 09:53:58 -0400 2010:
> Tengo un store procedure que dentro tiene una consulta, esa consulta al
> momento de correrla dentro del SP me demora unos 36 segundos, ahora bien; si
> ejecuto la misma (reemplazando los parametros por los mismos que l
2010/5/13 Alejandro D. Burne :
> Tengo un store procedure que dentro tiene una consulta, esa consulta al
> momento de correrla dentro del SP me demora unos 36 segundos, ahora bien; si
> ejecuto la misma (reemplazando los parametros por los mismos que le paso al
> SP) me demora unos 36 ms.
>
cheque
Gustavo Rosso escribió:
> Es 1.213ms un valor correcto para realizar un insert en una tabla
> obtenido por explain analyze.
Si preguntaras si 3.14 mmHg o -10s es un valor correcto, te diría que no. Pero
como tu valor tiene la unidad correcta y el signo correcto, no veo por
qué podría ser incorrec
27 matches
Mail list logo
