Re: [pgsql-es-ayuda] explain - esperaba el uso de índices

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

"Hash Join (cost=33335.39..1817942.71 rows=5692774 width=1002)"
" Hash Cond: ((h.clavebeneficiario)::text = (s.clavebeneficiario)::text)"
" -> Seq Scan on historicotemp h (cost=0.00..578624.74 rows=5692774
width=762)"
" -> Hash (cost=15677.73..15677.73 rows=394773 width=240)"
" -> Seq Scan on smiafiliados s (cost=0.00..15677.73 rows=394773
width=240)"

Ambas tablas tienen indexada la columna clavebeneficiario y como ven ambas
tablas creo que son lo suficientemente grande para la prueba.
(La tabla h tiene mas de 5 millones de registros y la tabla s tiene unos
400 mil registros)
Yo esperaba que al join lo haga utilizando índices, sin embargo veo que el
planificador no lo usa, ¿Tienen idea por qué?
Desde ya muchas gracias

Guillermo Villanueva

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" <guillermovil(at)gmail(dot)com>
escribió:

> 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
>
> "Hash Join (cost=33335.39..1817942.71 rows=5692774 width=1002)"
> " Hash Cond: ((h.clavebeneficiario)::text = (s.clavebeneficiario)::text)"
> " -> Seq Scan on historicotemp h (cost=0.00..578624.74 rows=5692774
> width=762)"
> " -> Hash (cost=15677.73..15677.73 rows=394773 width=240)"
> " -> Seq Scan on smiafiliados s (cost=0.00..15677.73 rows=394773
> width=240)"
>
> Ambas tablas tienen indexada la columna clavebeneficiario y como ven ambas
> tablas creo que son lo suficientemente grande para la prueba.
> (La tabla h tiene mas de 5 millones de registros y la tabla s tiene unos
> 400 mil registros)
> Yo esperaba que al join lo haga utilizando índices, sin embargo veo que el
> planificador no lo usa, ¿Tienen idea por qué?
> Desde ya muchas gracias
>
> Guillermo Villanueva
>
>

El día 26 de mayo de 2014, 10:23, Guillermo E. Villanueva
<guillermovil(at)gmail(dot)com> escribió:
> explain
> select *
> from
> nacer.historicotemp h
> inner join nacer.smiafiliados s on
> h.clavebeneficiario = s.clavebeneficiario;
>
> Con siguiente resultado
>
> "Hash Join (cost=33335.39..1817942.71 rows=5692774 width=1002)"
> " Hash Cond: ((h.clavebeneficiario)::text = (s.clavebeneficiario)::text)"
> " -> Seq Scan on historicotemp h (cost=0.00..578624.74 rows=5692774
> width=762)"
> " -> Hash (cost=15677.73..15677.73 rows=394773 width=240)"
> " -> Seq Scan on smiafiliados s (cost=0.00..15677.73 rows=394773
> width=240)"
>
> Ambas tablas tienen indexada la columna clavebeneficiario y como ven ambas
> tablas creo que son lo suficientemente grande para la prueba.
> (La tabla h tiene mas de 5 millones de registros y la tabla s tiene unos 400
> mil registros)
> Yo esperaba que al join lo haga utilizando índices, sin embargo veo que el
> planificador no lo usa, ¿Tienen idea por qué?

Eso es porque de todas formas va a tener que leer las dos tablas
completas para poder entregarte las tuplas que se generan con el JOIN.
Postgres sabe eso, y por lo tanto hace la busqueda secuencial (sino
tendria que usar el indice y después hacer una busqueda secuencial, lo
que es más costoso).

Agregale un LIMIT 100 al final y veras que usa los indices.

P.D.: Una consulta que retorna 5692774 filas no parece muy interesante.

Saludos,

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
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

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 índice, yo entiendo que por cada fila de h debe
buscar la coincidencia de la fila de s (s.clavebeneficiario es PK en s!) al
ser tan grande s y al tener que buscar una sola fila, ¿No es mas rápido con
el índice?

Desde ya muchas gracias

Guillermo Villanueva

El 26 de mayo de 2014, 14:24, Martín Marqués <martin(at)2ndquadrant(dot)com>escribió:

> El día 26 de mayo de 2014, 10:23, Guillermo E. Villanueva
> <guillermovil(at)gmail(dot)com> escribió:
> > explain
> > select *
> > from
> > nacer.historicotemp h
> > inner join nacer.smiafiliados s on
> > h.clavebeneficiario = s.clavebeneficiario;
> >
> > Con siguiente resultado
> >
> > "Hash Join (cost=33335.39..1817942.71 rows=5692774 width=1002)"
> > " Hash Cond: ((h.clavebeneficiario)::text =
> (s.clavebeneficiario)::text)"
> > " -> Seq Scan on historicotemp h (cost=0.00..578624.74 rows=5692774
> > width=762)"
> > " -> Hash (cost=15677.73..15677.73 rows=394773 width=240)"
> > " -> Seq Scan on smiafiliados s (cost=0.00..15677.73 rows=394773
> > width=240)"
> >
> > Ambas tablas tienen indexada la columna clavebeneficiario y como ven
> ambas
> > tablas creo que son lo suficientemente grande para la prueba.
> > (La tabla h tiene mas de 5 millones de registros y la tabla s tiene unos
> 400
> > mil registros)
> > Yo esperaba que al join lo haga utilizando índices, sin embargo veo que
> el
> > planificador no lo usa, ¿Tienen idea por qué?
>
> Eso es porque de todas formas va a tener que leer las dos tablas
> completas para poder entregarte las tuplas que se generan con el JOIN.
> Postgres sabe eso, y por lo tanto hace la busqueda secuencial (sino
> tendria que usar el indice y después hacer una busqueda secuencial, lo
> que es más costoso).
>
> Agregale un LIMIT 100 al final y veras que usa los indices.
>
> P.D.: Una consulta que retorna 5692774 filas no parece muy interesante.
>
> Saludos,
>
> --
> Martín Marqués http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

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 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 s (s.clavebeneficiario es PK en s!) al
> ser tan grande s y al tener que buscar una sola fila, ¿No es mas rápido con
> el índice?

Pero después igual va a tener que leer el dato de la tabla cuando tenga
que retornar *todas^las tuplas que se generan con el JOIN. Si de entrada
los lee, ya los tiene en memoria para retornarlos al cliente.

O sea, usar el índice, en este caso, es más costoso.

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
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

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 s (s.clavebeneficiario es PK en s!) al
> ser tan grande s y al tener que buscar una sola fila, ¿No es mas rápido con
> el índice?

No leíste el plan correctamente. Primero se recorre una tabla completa
(la que tiene como 300k tuplas), y cada tupla se mete en un hash.
Cuando el hash está listo, se lee la segunda tabla; para cada tupla de
la segunda se busca la correspondiente en el hash, NO leyendo la tabla
completa cada vez.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

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 <alvherre(at)2ndquadrant(dot)com>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 s (s.clavebeneficiario es PK en s!)
> al
> > ser tan grande s y al tener que buscar una sola fila, ¿No es mas rápido
> con
> > el índice?
>
> No leíste el plan correctamente. Primero se recorre una tabla completa
> (la que tiene como 300k tuplas), y cada tupla se mete en un hash.
> Cuando el hash está listo, se lee la segunda tabla; para cada tupla de
> la segunda se busca la correspondiente en el hash, NO leyendo la tabla
> completa cada vez.
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

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. Normalmente los títulos son variantes de
"Explaining EXPLAIN". Por ej.
http://momjian.us/main/presentations/internals.html#optimizer

Hay muchas otras presentaciones con láminas disponibles. Puedes buscar
en
https://wiki.postgresql.org/wiki/Category:PostgreSQL_Events

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)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

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án organizando para este año?

En Argentina ya estamos tanteando fechas, lugares, disertantes, pero
estaría bueno saber que pasa en otras partes. Hasta ahora solo se sabe
del PgDay de Cuba.

Alguien está organizando algo?

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

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 <alvherre(at)2ndquadrant(dot)com>escribió:

> 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. Normalmente los títulos son variantes de
> "Explaining EXPLAIN". Por ej.
> http://momjian.us/main/presentations/internals.html#optimizer
>
> Hay muchas otras presentaciones con láminas disponibles. Puedes buscar
> en
> https://wiki.postgresql.org/wiki/Category:PostgreSQL_Events
>
> 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)
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

http://momjian.us/main/writings/pgsql/optimizer.pdf
Excelente!

Guillermo Villanueva

El 26 de mayo de 2014, 20:25, Guillermo E. Villanueva <
guillermovil(at)gmail(dot)com> escribió:

> 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 <alvherre(at)2ndquadrant(dot)com>escribió:
>
> 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. Normalmente los títulos son variantes de
>> "Explaining EXPLAIN". Por ej.
>> http://momjian.us/main/presentations/internals.html#optimizer
>>
>> Hay muchas otras presentaciones con láminas disponibles. Puedes buscar
>> en
>> https://wiki.postgresql.org/wiki/Category:PostgreSQL_Events
>>
>> 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)
>>
>> --
>> Álvaro Herrera http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>

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 <martin(at)2ndquadrant(dot)com>escribió:

> 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án organizando para este año?
>
> En Argentina ya estamos tanteando fechas, lugares, disertantes, pero
> estaría bueno saber que pasa en otras partes. Hasta ahora solo se sabe
> del PgDay de Cuba.
>
> Alguien está organizando algo?
>
> --
> Martín Marqués http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

2014-05-26 20:54 GMT-03:00 Guillermo E. Villanueva <guillermovil(at)gmail(dot)com>:

> 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 haciendolo (no hay
nada confirmado todavía).
Yo por cuestiones personales no puedo organizar algo este año, pero con
gusto ayudo con los preparativos, el sitio web y difusión.

Igual creo que Martín preguntaba por otros PgDays en "latinoamerica",
quizas para colaborar y sobre todo para no solapar las fechas.
Yo agregaría también ir pensando algo más regional para 2015.

Por lo visto en los sitios no hay nada agendado por el momento:

http://www.postgresql.org/about/events/

https://wiki.postgresql.org/wiki/Events

Creo que tendríamos que seguir la conversación por las listas específicas
(pgsql-es-fomento o la lista de cada grupo de usuario, por ej arpug, a
ambas copie el mensaje), sacando a pgsql-es-ayuda para no mezclarlo con
temas técnicos.

Sds

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com

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 <ar(at)postgresql(dot)org> wrote:
>
> 2014-05-26 20:54 GMT-03:00 Guillermo E. Villanueva <guillermovil(at)gmail(dot)com>:
>> 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 haciendolo (no hay nada confirmado todavía).
> Yo por cuestiones personales no puedo organizar algo este año, pero con gusto ayudo con los preparativos, el sitio web y difusión.
>
> Igual creo que Martín preguntaba por otros PgDays en "latinoamerica", quizas para colaborar y sobre todo para no solapar las fechas.
> Yo agregaría también ir pensando algo más regional para 2015.
>
> Por lo visto en los sitios no hay nada agendado por el momento:
>
> http://www.postgresql.org/about/events/
>
> https://wiki.postgresql.org/wiki/Events
>
> Creo que tendríamos que seguir la conversación por las listas específicas (pgsql-es-fomento o la lista de cada grupo de usuario, por ej arpug, a ambas copie el mensaje), sacando a pgsql-es-ayuda para no mezclarlo con temas técnicos.
>
> Sds
>
> Mariano Reingart
> http://www.sistemasagiles.com.ar
> http://reingart.blogspot.com
>

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)
> Hablando de eso, que PgDays se están organizando para este año?

Hola a todos.

Supongo que ya habréis visto que la conferencia europea de
PostgreSQL este año (pgconf.eu) va a ser en Madrid.... y estamos
trabajando muy duro para que sea la mejor, con diferencia, de todas las
que ha habido (o eso esperamos ;))

Sé que a muchos os queda lejos..... pero merece la pena intentarlo.

Si hay suficientes ponentes, habrá además un track exclusivo en
español, así que todos los que podáis, enviad una propuesta al CFP
(http://2014.pgconf.eu/callforpapers/)

Saludos,

Álvaro

--
Álvaro Hernández Tortosa

-----------
8Kdata

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

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. ;)

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
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

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.

Esta es una idea que tenemos con Jaime. Ojalá se de.

Saludos,

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2014-05-26 14:34 GMT-05:00 Martín Marqués <martin(at)2ndquadrant(dot)com>:
>
> 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 987171157

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

Felipeguzmanv(at)gmail(dot)com escribió:
> Esperamos el de Chile, a ver sí Álvaro se anima!

Yo me animo a participar, pero confío en que nadie esté esperando que yo
lo organice!

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Copio lo que envio Jorge:

Chile se está quedando un poco atrasada en difución, a pesear de tener el
> único mayor contributor de latam. Creo que en parte se debe a que Alvaro
> está en el Sur de Chile. Espero que avancemos más en materia de difución de
> postgre. Debemos sacarle más partido al nivel que tenemos. Así que ánimo
> Chile.
>

Me parece super, entonces podemos generar más difución y a su vez generar
charlas de PostgreSQL, Alvaro si te animas podemos ayudar a organizar estas
charlas!! y por que no exponer de alguna tematica tambien.

Saludos

El 28 de mayo de 2014, 6:16, Jorge Medina <jorge(at)bsdchile(dot)cl> escribió:

>
>
>
> 2014-05-27 3:21 GMT+02:00 Felipeguzmanv(at)gmail(dot)com <felipeguzmanv(at)gmail(dot)com
> >:
>
> Esperamos el de Chile, a ver sí Álvaro se anima!
>>
>> Saludos
>>
>
> Chile se está quedando un poco atrasada en difución, a pesear de tener el
> único mayor contributor de latam. Creo que en parte se debe a que Alvaro
> está en el Sur de Chile. Espero que avancemos más en materia de difución de
> postgre. Debemos sacarle más partido al nivel que tenemos. Así que ánimo
> Chile.
>
> Saludos.
>
> Sent from my iPad
>>
>> On 26-05-2014, at 21:08, PostgreSQL RC Argentina <ar(at)postgresql(dot)org>
>> wrote:
>>
>> 2014-05-26 20:54 GMT-03:00 Guillermo E. Villanueva <
>> guillermovil(at)gmail(dot)com>:
>>
>>> 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 haciendolo (no hay
>> nada confirmado todavía).
>> Yo por cuestiones personales no puedo organizar algo este año, pero con
>> gusto ayudo con los preparativos, el sitio web y difusión.
>>
>> Igual creo que Martín preguntaba por otros PgDays en "latinoamerica",
>> quizas para colaborar y sobre todo para no solapar las fechas.
>> Yo agregaría también ir pensando algo más regional para 2015.
>>
>> Por lo visto en los sitios no hay nada agendado por el momento:
>>
>> http://www.postgresql.org/about/events/
>>
>> https://wiki.postgresql.org/wiki/Events
>>
>> Creo que tendríamos que seguir la conversación por las listas
>> específicas (pgsql-es-fomento o la lista de cada grupo de usuario, por ej
>> arpug, a ambas copie el mensaje), sacando a pgsql-es-ayuda para no
>> mezclarlo con temas técnicos.
>>
>> Sds
>>
>> Mariano Reingart
>> http://www.sistemasagiles.com.ar
>> http://reingart.blogspot.com
>>
>>
>
>
> --
> Jorge Andrés Medina Oliva.
> Computer engineer.
>

--
Atentamente

*
Felipe Guzmán Vargas*
*Ingeniero en Informatica - Consultor TI*
*www.desarrollamostuidea.cl* <http://www.desarrollamostuidea.cl>

>
> 2014-05-26 14:34 GMT-05:00 Martín Marqués <martin(at)2ndquadrant(dot)com>:
>>
>> 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