Re: lpad vs ||

From: Andrés P(dot)P(dot) <solopostgres(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: lpad vs ||
Date: 2010-09-03 20:54:18
Message-ID: AANLkTinfg3s58XuNbYv_6y+J66nXjy6r7tnZp8RHJDgF@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hola Álvaro

Los updates que te mostré son aplicados a dos tablas "diferentes"... tabla1
y tabla2 ......pero la data que hay en cada una de ellas y el resultado de
ambos updates es el mismo... hice esto para comparar si el uso del lpad era
mejor o no que usar concatenación con || sobre el mismo grupo de
datos........

Dentro del universo de data que hay.. tengo valores que puedo clasificar en
largo 12 y 13.... pero la prueba la realicé en ambas tablas pero con un caso
solamente (12).... y la consulta sobre el momento de aplicar el vacuum iba
orientado justamente a estos dos updates que debo hacer por separado (12 y
13).

Ahora, respecto al tiempo..... claro, extrapolando de acuerdo a la
proporción de data yo también calculaba 200sg..... pero justamente en estos
momentos acaba de terminar un update sobre la tabla completa (13.000.000)
y afectó a unos 6 millones de registros..... y el tiempo fue de 15 minutos.
seguramente los 7 millones restantes (con vacuum previo) debiera ser un poco
más.... Encuentro buen tiempo pero por curiosidad cognitiva me gustaría
entender la diferencia en esta proporción... talvez el hecho de escribir en
la tabla, escribir en el índice y al mismo tiempo usar el índice??..

Finalmente, la solución que me indicas de eliminar el único índice que hay
significaría eliminar la PK.. y el campo de esta PK es justamente el que se
modifica y que también se usa en el where....... Viendo lo anterior... es
más óptimo hacer el update sobre la tabla sin el índice .... que
hacerlo con la "ayuda" que proporciona la presencia del mismo índice en el
where??...

Gracias por la respuesta. (y perdona lo extenso).

Sds.
Andrés

El 3 de septiembre de 2010 14:19, Alvaro Herrera <alvherre(at)commandprompt(dot)com
> escribió:

> Excerpts from Andrés P.P.'s message of jue sep 02 21:45:30 -0400 2010:
> > Estimados listeros
> >
> > Necesito confirmación a lo siguiente: hice dos updates sobre tablas cuya
> > definición y carga fueron iguales:
> > *En Desarrollo :*
> >
> > upd1) update tabla1 set valor = lpad(substr(valor,4,9),11,76) where
> > length(valor)=12; 21867.891 ms
> > upd2) update tabla2 set valor = 76||substr(valor,4,9) where
> > length(valor)=12; *21119.145 ms*
> >
> > (valor es la PK de la tabla,varchar y no hay más índices)
> >
> > Ambas tablas de pruebas tienen *1.300.000* registros, 650.000 tienen un
> > length(valor)=12 y los 650.000 restantes un length(valor)=13.
>
> Los dos update cambian los registros con length(valor) = 12. ¿Hay un
> error?
>
>
> > *Real :*
> >
> > En producción la tabla es de *13.000.000* de registros. Sobre ésta debo
> > hacer 2 updates.. para length(valor)=12 y 13.
> > El server está levemente mejor equipado en procesadores y ram que en
> > desarrollo.(y asumiendo lo mismo en velocidad de disco).
> > Preguntas:
> >
> > - Asumo que el upd2 seguirá siendo más rápido?
>
> No
>
> > - Dejo el vacuum para el final?.. o después del 2do. update?
>
> Te conviene antes del segundo update. Si no hubiera índice en la
> columna que estás cambiando, daría lo mismo (debido a HOT), pero no es
> el caso. Quizás te convenga botar los índices de la tabla antes de
> hacer los update, luego vacuum, luego reconstruir los índices.
>
> > - Asumo que el tiempo será mayor en la misma proporción del nuevo nro. de
> > registros??. Osea puedo pensar que demorará aprox. *200000* ms??..
>
> Mídelo, 200 segundos no es tanto. Pero yo creo que debería tardar más.
>
> > y lo último: tienen alguna alternativa para estos updates en 8.2.5 ??..
> > vi por ahí una línea para hacer un update único mezclando en el set el
> > lenght y el substr.... pero no me pareció eficiente..
>
> Si vas a cambiar los mismos registros, te conviene hacerlo todo de una
> vez.
>
> --
> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2010-09-03 20:59:34 Re: lpad vs ||
Previous Message Gerardo Herzig 2010-09-03 20:40:41 estadistica de uso del cache