Uff, este ejercicio me ayudo a saber/aclarar los siguientes puntos:
A: un group by y distinct hacen lo mismo ( si no hay funciones de
agregación ), realmente no tenia idea de este punto antes, jamas había
usado group by para eliminar duplicados.
B: hacer un distinct con un join en postgresql
Perdon. Una aclaración solo para probar rápido una posible mejora. Si haces
un cast implícito como el corte de fechas, estoy casi seguro que el motor
hace full scan. Proba googleando como hacer un indice con una función en
postgres (se puede). Sino ese corte manejalo sin castear tipos de datos.
2016-02-22 17:45 GMT-05:00 Horacio Miranda :
> Pregunta tonta
>
> Para que quieres hacer un group by ? cuando no hay funciones que necesiten
> un group by ?
>
Además del tema de los gatitos (que me parecio genial), este es el
punto mejor pensado que encontre en este hilo.
El GROUP BY es claram
Hola a todos
A todos los que estuvimos al pendiente de este muy instructivo
tema, quiero dejar este link por aquí, tarde lo sé, pero no
lo recordé si no hasta hoy que tuve que solucionar algo
parecido, pero menos complejo.
http://explain.depesz.com
Ingresas el plan de ejecución y te arroja un a
Hola Horario
Si, tenemos una tarea pendiente de ajustar la carga de la informacion
externa, actualmente el servidor se encuentra en la versión 9.4 por lo
tanto UPSERT no esta disponible, vamos a trabajar en ese tema. Muchas
Gracias por sus comentarios y tiempo.
El 23 de febrero de 2016, 17:39,
On 2/24/2016 4:30 AM, Alvaro Herrera wrote:
Hellmuth Vargas escribió:
Ejecute el EXPLAIN ANALYZE y lo termine a los 4 minutos sin resultados
Cuando tengas tiempo (por ej. justo antes de irte de la oficina), deja
la consulta corriendo varias horas para tener un EXPLAIN ANALYZE. No
sirve de
Hellmuth Vargas escribió:
> Ejecute el EXPLAIN ANALYZE y lo termine a los 4 minutos sin resultados
Cuando tengas tiempo (por ej. justo antes de irte de la oficina), deja
la consulta corriendo varias horas para tener un EXPLAIN ANALYZE. No
sirve de nada que lo estés cortando a los 4 minutos, porq
Hola Horacio
Muchas gracias por el tiempo y la dedicación al tema, voy respondiendo sus
preguntas:
- Los datos son insertados por un servicio externo (web service) de forma
permanente por lo tanto no tenemos control sobre los datos que vienen
- Por la misma razón del punto anterior no se puede de
Lo único que se me ocurre a esta altura es crear una vista materializada
para tu consulta y que corra en la noche...
Si quieres usar vistar mira este link.
http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-refresh-concurrently-a-materialized-view/
On 2/23/2016 11:54 AM, H
Si decides irte por Vistas materializadas pegale una mirada a esto
http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-refresh-concurrently-a-materialized-view/
On 2/23/2016 11:54 AM, Hellmuth Vargas wrote:
Hola Horacio
El group by es porque originalmente había un distinct
Puedes probar invirtiendo las tablas, colocando cajeros al comienzo ? (
tiene menos registros ).
De momento estoy revisando y no veo como optimizar la consulta ( y estoy
comparando entre Oracle y Postgresql), Oracle genera una vista para
mejorar el tiempo de la consulta, pero puede ser por los
Solo para aclarar, los planes de ejecución de un distinct y group by (
cuando no se usan funciones de agregación ) son iguales.
Por simplicidad y objetividad ( ya que quieres registros no duplicados
), te sugiero usa distinct.
Ahora una pregunta, puedes ver si tus datos están duplicados ?
Ti
On 2/23/2016 12:37 PM, Horacio Miranda wrote:
Acabo de volver y si es super lento, estaba pensando en prepared
statement ( o el equivalente a variables Bind de Oracle en postgresql ).
voy a ver de que se trata generate_series.
On 2/23/2016 12:21 PM, Alvaro Herrera wrote:
Horacio Miranda escri
Acabo de volver y si es super lento, estaba pensando en prepared
statement ( o el equivalente a variables Bind de Oracle en postgresql ).
voy a ver de que se trata generate_series.
On 2/23/2016 12:21 PM, Alvaro Herrera wrote:
Horacio Miranda escribió:
Estoy revisando en este momento, estoy h
Horacio Miranda escribió:
> Estoy revisando en este momento, estoy haciendo ( una brutalidad pero voy a
> salir a comer algo asi que no problema que quede corriendo ).
>
> for j in $(seq 1 200) ; do
> for i in $(seq 1 1) ; do
> psql lentitud -c \
> "insert into ath_cajerosv2 (fecha,id_
Estoy revisando en este momento, estoy haciendo ( una brutalidad pero
voy a salir a comer algo asi que no problema que quede corriendo ).
for j in $(seq 1 200) ; do
for i in $(seq 1 1) ; do
psql lentitud -c \
"insert into ath_cajerosv2 (fecha,id_usuario,usuario) values (now() -
inte
Hola Horacio
El group by es porque originalmente había un distinct porque salen
registros duplicados ( son registros de trazas según me dicen) por lo
tanto cambie el distinct por group by pues es más óptimo. Igual lo retire
en un principio y tampoco obtuvo resultados.
El feb. 22, 2016 5:45 PM, "
Pregunta tonta
Para que quieres hacer un group by ? cuando no hay funciones que
necesiten un group by ?
Puedes correr la consulta sin el group by for favor.
PS: ahora tengo tiempo para mirar esto y estoy viendo como crear datos...
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-a
Horacio Miranda escribió:
> Estoy de acuerdo con Alvaro, claro que no tengo idea de donde salio ese tema
> de los gatitos muertos...
Es una tontera ilustrativa solamente.
> Estan las definiciones de las tablas voy a hacer un lab para ver si
> reproduzco el error en unas horas ( estoy trabajando
On 2/23/2016 10:57 AM, Alvaro Herrera wrote:
Hellmuth Vargas escribió:
Hola Mario
Ajuste los parámetros y no se ve gran cambio, tanto con el work_mem por
default como con el de 2048 MB, ya no adjunto imagen pues por el tamaño del
mensaje no lo permite la lista.
Estimados, no es necesario ad
Hellmuth Vargas escribió:
> Hola Mario
>
> Ajuste los parámetros y no se ve gran cambio, tanto con el work_mem por
> default como con el de 2048 MB, ya no adjunto imagen pues por el tamaño del
> mensaje no lo permite la lista.
Estimados, no es necesario adjuntar las mismas imágenes una y otra vez
..@postgresql.org] *En nombre de *Hellmuth Vargas
>> *Enviado el:* lunes, 22 de febrero de 2016 16:35
>> *Para:* Eduardo Morras < emorr...@yahoo.es>
>> *CC:* Lista Postgres ES <
>> pgsql-es-ayuda@postgresql.org>
>> *Asunto:* Re: [pgsql-es-ayuda] join super lento
&
@postgresql.org
<mailto:pgsql-es-ayuda-ow...@postgresql.org>] *En nombre de
*Hellmuth Vargas
*Enviado el:* lunes, 22 de febrero de 2016 16:35
*Para:* Eduardo Morras mailto:emorr...@yahoo.es>>
*CC:* Lista Postgres ES mailto:pgsql-es-ayuda@postgresql.org>>
*A
16:35
> *Para:* Eduardo Morras
> *CC:* Lista Postgres ES
> *Asunto:* Re: [pgsql-es-ayuda] join super lento
>
>
>
>
>
>
>
> Hola Antony
>
>
>
> Pues, restaure indices y lleve el work_mem hasta 4096 MB (la tercera
> parte de la RAM del
Morras
CC: Lista Postgres ES
Asunto: Re: [pgsql-es-ayuda] join super lento
Hola Antony
Pues, restaure indices y lleve el work_mem hasta 4096 MB (la tercera parte de
la RAM del servidor) y pasaron 4 minutos y nada.
set local work_mem='4096 MB'
Hola Antony
Pues, restaure indices y lleve el work_mem hasta 4096 MB (la tercera
parte de la RAM del servidor) y pasaron 4 minutos y nada.
set local work_mem='4096 MB'
select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
t.horaact, t.usuario, t.identificacionusuario, t.tipomovim
On Mon, 22 Feb 2016 09:55:21 -0500
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),
> 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
28 matches
Mail list logo
