>
> 2014-05-26 14:34 GMT-05:00 Martín Marqués :
>>
>> Alguien está organizando algo?
>>
>
> Yo ya empece a organizar el 4to PgDay Ecuador, veamos si concreta!
En Cuba estamos organizando el evento nacional como cada año, ver:
http://postgresql.uci.cu/
Saludos,
Gilberto Castillo
La Habana, Cuba
2014-05-26 14:34 GMT-05:00 Martín Marqués :
>
> Alguien está organizando algo?
>
Yo ya empece a organizar el 4to PgDay Ecuador, veamos si concreta!
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 9871711
El 26/05/14 22:08, PostgreSQL RC Argentina escribió:
>
> Igual creo que Martín preguntaba por otros PgDays en "latinoamerica",
> quizas para colaborar y sobre todo para no solapar las fechas.
Y para tener una escusa para viajar. ;)
> Yo agregaría también ir pensando algo más regional para 2015.
El 26/05/14 20:54, Guillermo E. Villanueva escribió:
> La verdad que no se, Mariano? Andas por ahí? qué pinta para este año?
> En el 2013 yo no pude ir a Bs As
Este año estábamos pensando en otra ciudad, pero esta complicado. Vamos
a ver como va cuajando.
Posiblemente sea más cerca de Salta. ;)
On 26/05/14 21:34, Martín Marqués wrote:
El 26/05/14 16:16, Alvaro Herrera escribió:
Por supuesto, lo mejor es _ir_ a una de las conferencias. No hay
sustituto a invitar a un desarrollador a una(s) cervezas y que te
explique el optimizador (después de haber estado en la charla, por
supuesto)
Esperamos el de Chile, a ver sí Álvaro se anima!
Saludos
Sent from my iPad
> On 26-05-2014, at 21:08, PostgreSQL RC Argentina wrote:
>
> 2014-05-26 20:54 GMT-03:00 Guillermo E. Villanueva :
>> La verdad que no se, Mariano? Andas por ahí? qué pinta para este año?
>> En el 2013 yo no pude ir a B
2014-05-26 20:54 GMT-03:00 Guillermo E. Villanueva :
> La verdad que no se, Mariano? Andas por ahí? qué pinta para este año?
> En el 2013 yo no pude ir a Bs As
>
>
Este año en Argentina puede que sea en Córdoba o Santa Fé, para la fecha
"tradicional" de mediados de Noviembre en que venimos haciend
La verdad que no se, Mariano? Andas por ahí? qué pinta para este año?
En el 2013 yo no pude ir a Bs As
Guillermo Villanueva
El 26 de mayo de 2014, 16:34, Martín Marqués escribió:
> El 26/05/14 16:16, Alvaro Herrera escribió:
> >
> > Por supuesto, lo mejor es _ir_ a una de las conferencias. No
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,
El 26/05/14 16:16, Alvaro Herrera escribió:
>
> Por supuesto, lo mejor es _ir_ a una de las conferencias. No hay
> sustituto a invitar a un desarrollador a una(s) cervezas y que te
> explique el optimizador (después de haber estado en la charla, por
> supuesto)
Hablando de eso, que PgDays se est
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
Buenos días, se que ya hubieron muchas preguntas al respecto pero este caso
me llama la atención y los molesto consultando.
Tengo la siguiente query:
explain
select *
from
nacer.historicotemp h
inner join nacer.smiafiliados s on
h.clavebeneficiario = s.clavebeneficiario;
Con siguiente resultado
"
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
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 tiempo que demora en retornar
Buenas noches, si alguno de uds tiene tiempito, se anima a explicarme la
salida del explain analyze y si es posible tomar como ejemplo la sentencia
select que estoy tratando de optimizar? Desde ya muchas gracias!!
*La sentencia es:*
EXPLAIN ANALYZE SELECT
coalesce(historicotemp.afiapellido, '')
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
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.
El problema es que no puedo hacer un explain par
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
Es 1.213ms un valor correcto para realizar un insert en una tabla obtenido por
explain analyze.
Gustavo
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html
Hola listeros
Ando buscando informacion sobre explain analyze, lo unico que he
encontrado en la web es para que sirve y un par de ejemplos , pero no algun
manual que me permita interpretarlo, algunos conceptos se entienden pero no
en su totalidad, si me pudiesen ayudar de antemano muchas gr
42 matches
Mail list logo
